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Abstract 

In 1991, Pfenning and Lee studied whether System F could sup¬ 
port a typed self-interpreter. They concluded that typed self¬ 
representation for System F “seems to be impossible”, but were 
able to represent System F in F„. Further, they found that the rep¬ 
resentation of F„ requires kind polymorphism, which is outside 
F w . In 2009, Rendel, Ostermann and Hofer conjectured that the 
representation of kind-polymorphic terms would require another, 
higher form of polymorphism. Is this a case of infinite regress? 
We show that it is not and present a typed self-representation for 
Girard’s System U, the first for a A-calculus with decidable type 
checking. System U extends System F„ with kind polymorphic 
terms and types. We show that kind polymorphic types (i.e. types 
that depend on kinds) are sufficient to “tie the knot” - they enable 
representations of kind polymorphic terms without introducing an¬ 
other form of polymorphism. Our self-representation supports op¬ 
erations that iterate over a term, each of which can be applied to 
a representation of itself. We present three typed self-applicable 
operations: a self-interpreter that recovers a term from its represen¬ 
tation, a predicate that tests the intensional structure of a term, and 
a typed continuation-passing-style (CPS) transformation - the first 
typed self-applicable CPS transformation. Our techniques could 
have applications from verifiably type-preserving metaprograms, 
to growable typed languages, to more efficient self-interpreters. 

Categories and Subject Descriptors D.3.4 [ Processors ]: Inter¬ 
preters; D.2.4 [Program Verification ]: Correctness proofs, formal 
methods 

General Terms Languages; Theory 

Keywords Lambda Calculus; Self Representation; Types 

1. Introduction 

Typed self-representation is the problem of representing a stati¬ 
cally typed language in itself. It can be seen as the intersection 
of two lines of research: self-representation, which generally stud¬ 
ies representations of untyped or dynamically typed languages in 
themselves, and typed representation, which studies techniques for 
defining typed representations of statically typed languages that en¬ 
sure only well-typed programs can be represented. 



In general, the techniques required for building a representation 
depend upon both the meta-language (in which the representation 
is defined) and the object language (which is represented). Rep¬ 
resentations of expressive object language features tend to require 
even more expressive meta-language features. In the case of a self¬ 
interpreter, the meta-language and the object language are the same. 
The key challenge of typed self-representation is to identify a sin¬ 
gle typed language that is expressive enough to represent each of 
its own features, without additional expressive power. 

Language — 


Representation 

In our case, we are interested in typed A-calculi with decid¬ 
able type checking. It has been an open question since 1991 [26] 
whether a typed A-calculus with decidable type checking can sup¬ 
port a meaningful notion of typed self-representation. 

Self Representation. Self-representation and self-interpretation 
have many important applications. A self-interpreter can be used 
to grow a language from a small core implemented in some other 
meta-language. One can use similar techniques to implement self- 
optimizers and compilers, as well as debuggers, read-eval-print- 
loops, and macro systems. A similar idea is the reflective tower, 
which uses an infinite tower of self-interpreters to add reflective 
capabilities to a language. 

There are many examples of self-interpreters in the literature, 
including ones for A-calculus [4, 7, 8, 18, 22, 23, 28, 31], Haskell 
[25], JavaScript [13], Lisp [21], Python [36], Ruby [37], Scheme 
[2], Standard ML [29], and many others [19, 32, 38], In each 
of these the representations are untyped, in the sense that (1) it 
is possible to build representations of ill-typed terms, and (2) all 
representations are either untyped or else have the same type. 

Typed Representation. We can contrast this with typed repre¬ 
sentations, which have two essential properties: (1) only well-typed 
terms can be represented, and (2) the type of a term is reflected in 
the type of its representation, in the sense that the former can be 
determined by the latter. This provides important correctness guar¬ 
antees for metaprograms. An immediate consequence of (1) is that 
a metaprogram cannot produce ill-typed terms. We can also ensure 
that the types of its input and output terms are related in a particu¬ 
lar way. For example, we can ensure that a self-interpreter preserves 
the type of its input, or that a continuation-passing-style transfor¬ 
mation modifies the type of the input program in the expected way. 

There are many examples in the literature of typed representa¬ 
tions. In most cases the techniques rely on the fact that the meta¬ 
language has a more powerful type system than the object lan¬ 
guage. 

Typed Self-Representation. The goal of typed self-represent¬ 
ation is to combine the benefits of self-representation and typed 
representation. It promises the best of both worlds: on the one 




hand, it brings the expressive power of self-representation to the 
world of statically typed languages. On the other hand, it brings the 
correctness guarantees of types to self-applicable metaprograms. 
A robust typed self-representation would support typed variants of 
the kinds of applications enabled by self-representation. It would 
also narrow the expressiveness gap between dynamically typed 
languages and statically typed languages, allowing more classical 
programs from dynamically typed languages to be statically type 
checked. 

What does it mean for a language to support typed self¬ 
representation? We have adopted two primary requirements: that 
our language be a typed A-calculus with decidable type-checking, 
and that a representation support operations that iterate over the 
structure of the term. Further, we want to allow operations that pro¬ 
duce results of different types, possibly related to the type of the 
input representation. 

We target a typed self-recognizer [17], which is a self-interpreter 
that recovers a term from its representation. The idea of a self¬ 
recognizer was first studied by Kleene [18] in 1936 for an untyped 
A-calculus. There are several examples of typed recognizers and 
self-recognizers [26, 27] that are implemented by iteration. Iter¬ 
ation is desirable because it can be supported by languages that 
don’t include recursion. An operation that iterates or folds over the 
term is defined by cases - one case for each syntactic form. 

In the case of a pure A-calculus (that contains only abstractions, 
applications, and variables), we have identified a core challenge 
that is related to typed self-representation. The Polymorphic Ap¬ 
plication (polyapp) problem is to define a polymorphic application 
function for each form of application in the language. For example, 
System F terms can be applied to terms and to types. The polyapp 
problem for System F is to define a polymorphic application func¬ 
tion that can apply terms to terms, and a polymorphic application 
function that can apply terms to types. In Section 3.2 we present a 
general technique for implementing polyapp functions by decom¬ 
posing types. In subsequent sections we leverage this technique to 
represent terms and types. 

History. Typed self-representation of A-calculi has been stud¬ 
ied since at least 1991, when Pfenning and Lee [26] considered 
whether System F could support a typed self-recognizer. Pfenning 
and Lee concluded that the problem “seems to be impossible”, but 
were able to implement a typed recognizer for System F represen¬ 
tations in F„. Furthermore, they were able to implement F„ in F+, 
which extends F w with kind polymorphic terms. They did not study 
representation of Fj. 

In 2009 Rendel, Ostermann and Hofer [27] studied the repre¬ 
sentation of kind polymorphism, and conjectured that it would re¬ 
quire “another, higher form of polymorphism”. Their solution was 
to combine the categories of types and kinds, so that kind polymor¬ 
phism is represented in the same way as type polymorphism. They 
demonstrated the first typed self-representation and first typed self¬ 
recognizer for a A-calculus, though their calculus does not support 
decidable type checking. 

In 2011 Jay and Palsberg [17] implemented a typed self¬ 
interpreter for a combinator calculus with System F types. They 
implemented a self-recognizer and the first typed self-enactor, a 
self-interpreter that implements multi-step reduction on typed rep¬ 
resentations. Like [27], type checking is undecidable in their calcu¬ 
lus. Their representation technique was designed for combinators, 
and does not appear to be easily translated to a A-calculus. 

Tying the Knot. A challenge of representing a typed A-calculus 
is to find techniques for representing each form of abstraction and 
application in the language without adding any new ones. Pfenning 
and Lee represented System F type abstraction and application us¬ 
ing the higher order types of F^. In particular, they used higher or¬ 
der types to represent System F type abstractions and applications. 
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Figure 1 . Four typed A-calculi: — > denotes “represented in.” 


We can demonstrate their technique using a polymorphic type ap¬ 
plication function. 

A type application function for System F type applications 
should map a polymorphic term and a type to the application of 
the term to the type. For example, given a term of type Va. a —¥ a 
and a type r, the type application function should return a term of 
type t —^ t. We can define the type application function for this 
case as Aa: : (Va. a -► a). A/?. ® p. 

A polymorphic type application function for System F should 
be able to apply any polymorphic term. In other words, it should be 
polymorphic in the type of the term, and the type of the term must 
itself be polymorphic. What is needed is a way to abstract over ex¬ 
actly the polymorphic types of System F, excluding monomorphic 
types like a — ¥ ft. This is beyond the capabilities of System F type 
abstraction. 

Pfenning and Lee solved this problem by encoding quantified 
types as second-order types in System F w . For example, the type 
Va. a —> a can be encoded as the second-order type Aa : *. a —> 
a. The types of F„ are classified by a family of kinds. First-order 
types like n —¥ T2 have kind *, and second-order types like 
A a a a have kind * —>- *. Type abstractions in F„ 

range over a particular kind that is specified by an annotation. We 
can abstract over encodings of System F quantified types using 
a type abstraction annotated with kind * —> *. This enables a 
polymorphic type application function for System F quantified 
types to be implemented as: 

Act :*—»*. Ax : (Va : *. a a). A/3 : *. x /? 

In F„, the type of this term is Vcr : * —»• *. (Va : *. a a) — f (V/3 : 
*. a /3). The type Va : *. a a represents an arbitrary quantified 
type. Substituting a with an encoded quantified type recovers the 
quantified type. For example, substituting a with Aa : *. a — > a 
yields Va : *. (Aa : *. a —> a) a, which is equivalent to 
Va : *. a —> a. Note that Va : *. a —¥ a is the F w version 
of Va. a —> a. Since every System F quantified type can be 
encoded as an F w type of kind * —» *, this type application 
function can apply any polymorphic System F term. It can only 
apply polymorphic terms, because no substitution for a can make 
(Va : *. a a) into a monomorphic type. 

Pfenning and Lee used this technique to represent System F 
in F„. They were unable to represent System F w in itself, but did 
achieve a representation of F w in F+, which extends F„ with kind 
abstraction and application in terms. It is easy to imagine that this 
is a case of infinite regress; that representing kind-abstractions will 
require another extension, which will also need to be represented if 
we hope to achieve self-representation. 

The System F type application function discussed above already 
hints at the question of infinite regress. It can apply any polymor¬ 
phic term typeable in System F, but is not itself typeable in System 
F. On the other hand, it is typeable in System F„, but can only apply 
some of the polymorphic terms in F w . In particular, it cannot apply 
itself. This begs the following question, which we name the Poly¬ 
morphic Application problem: is it possible to define a set of poly¬ 
morphic application functions in a particular language, one for each 
form of application in the terms of that language (e.g., for applica¬ 
tions of terms to terms, terms to types, terms to kinds, etc.)? We 
conjecture that a language that supports typed self-representation 
can also support polymorphic application. 



In Section 3.2 we formalize the Polymorphic Application prob¬ 
lem and present a solution for Girard’s System U. In later sections 
we use our solution to define our typed self-representation for Sys¬ 
tem U. Our result is summarized in Figure 1. Pfenning and Lee 
were able to represent System F in F„, and F„ in F+. We show 
that F+ can be represented in System U, and that System U can 
represent itself. 

System U. System U was first introduced by Jean-Yves Girard 
in his PhD thesis [16], in which he also introduced System F. 
Girard used System U to formalize a version of the Burali-Forti 
paradox. Girard’s paradox showed that System U is not strongly 
normalizing, and that every type is inhabited. Thus, as a logic, 
System U is inconsistent. 

System U is a Pure Type System that lies outside the A-cube 
[5], and that does not include dependent types. It is an extension of 
F+, and every legal Fj term is a legal System U term. The terms 
of System U consist of variables and abstractions and applications 
of each of terms, types, and kinds. The types of System U consist 
of variables and abstractions and applications of each of types and 
kinds. Intuitively, the types of System U are the terms of System F. 
In Section 3.2 we show that System U can support a polymorphic 
application function for each form of application. A key property 
that makes tying the knot possible is that System U does not have 
higher-order kinds. As a result, there is no “type system” for kinds: 
all kinds are classified by a single sort □. This is analogous to the 
types of System F: System F does not have higher-order types, and 
all types are classified by a single sort *. Since System U has only 
one classifier of kinds, a representation of System U does not need 
to abstract over classifiers of kinds. 

Representation and Operations. We represent both terms and 
the types of terms. We call our term representation procedure “quo¬ 
tation”. In section 5, we define a meta-level process of quotation, 
which formalizes what it means for one term to represent another. 
In the diagram above, our quotation function quote maps a typed 
term to its representation. Unlike the other operations in the figure, 
quote is defined outside the language itself. 
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We support operations that iterate or fold over the representation. 
In section 6 we present three example operations defined as folds: 
a self-recognizer unquote that recovers a term from its representa¬ 
tion, a predicate isAbs that tests the intensional structure of a rep¬ 
resentation, and a typed continuation-passing style (CPS) transfor¬ 
mation. CPS transformation is often used in compilers of functional 
programming languages. 

Our Results. We identify System U as the first known typed 
A-calculus with decidable type checking that supports typed self¬ 
representation. We represent both terms and the types of terms, 
which enables operations that transform the type of their input. 
Type representations are essential to our implementation of the first 
typed self-applicable CPS transformation. The result type of the 
CPS transformation is a function of the intensional structure of the 
input type. 

Our type representations are types of a particular kind U. Type 
representations are used to type check term representations. For ex¬ 
ample, suppose that e is a term of type r, that q is the representa¬ 




tion of e, and that a is the representation of r. Then the type of 
q is Exp a. Our self-recognizer unquote recovers a term from its 
representation, so that unquote a q=p e. The type of unquote is 
lien : U. Exp a —> UId a. In Pure Type Systems, II is analogous to 
the V quantifier of System F and F^. The type UId is an operation 
on type representations that recovers a type from its representation. 
For example UId cr =p r. 

Rest of the Paper. Section 2 gives an overview of Pure Type 
Systems, Section 3 describes System U, Section 4 defines our rep¬ 
resentation of types. Section 5 defines our representation of terms, 
Section 6 presents our example operations. Section 7 discusses our 
implementation and experimental results. Section 8 contains a com¬ 
parison with related work, Section 9 discusses future work, and 
Section 10 concludes. Proofs of theorems stated throughout the pa¬ 
per are provided in the appendix of the full paper, which is available 
from our website [1], 

2. Pure type systems 

We use Barendregt’s [5] formalization of System U as a Pure Type 
System (PTS). This section gives an overview of some important 
aspects of PTSs for the unfamiliar reader, but does not include a 
detailed tutorial. Pure Type Systems have a uniform syntax, which 
helps to clarify both the presentation of our self-representation 
techniques, and a comparison between System U and other PTS 
instances like System F and F„. The comparison serves to ex¬ 
plain what parts of System U are important for achieving a self¬ 
representation. 

A Pure Type System is defined by a set of expressions T and a 
specification. The expressions are defined by the grammar: 

T=V\C\XV :T.T\TT\UV :T.T 

Here V ranges over a countable set of variables and C ranges over a 
set of constants. We use x,y to range over variables, c to range over 
constants, and a,b,A, and B to range over expressions. Functionals 
are introduced by the A form and eliminated by application. The 
form I1V : T- T introduces a product, which is used to classify 
functionals. 

The notation A —B denotes that A reduces to B in one step of 
/3-reduction. Similarly, A B denotes that A reduces to B in one 
step of ^-reduction, and A B denotes that either A B or 
A —trj B. The relation -»£ denotes the reflexive transitive closure 
of — yp, and =p denotes the least congruence relation generated by 
—ip. The relations -» v , = v , -»prj , and =g rl are defined similarly. 

A specification of a PTS consists of a triple (S. A, 1Z). The first 
component S is a subset of C called sorts. We will use s to range 
over sorts. In the systems we consider, all constants are sorts. The 
second component A is a set of axioms of the form c : s, where 
c is a constant and s a sort. The third component 1Z is a set of 
rules of the form (si, «2, S3), for some sorts si, S2, and S3. We use 
the shorthand (si, S2) to denote (si, S2, S2). The specification and 
a set of derivation rules determine the derivable typing judgments 
T h A : B. 

In a judgment of the form T h A : B, we call A the subject and 
B the classifier of A. If T h A : B can be derived using the rules 
in Figure 2 with the specification of a particular PTS, then A is 
legal in that system. Some authors call the set of legal expressions 
the terms, though we will use term to refer to a subset of the legal 
expressions defined below. 

We call a product derived with the rule (si,S2,S3) as its 
side-condition an “(si,S2,«3) product”. The rule ensures that a 
(si, S2, S3) product will be classified by S3. A product nx : A. B 
is called a dependent product if x occurs free in B. It is standard to 
abbreviate products nx : A. B as A —> B when x does not occur 
free in B. It is sometimes possible to determine that an arbitrary 
(si, S2, S3) product can be written in this abbreviated form. For 
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Figure 3. PTS specifications of key calculi 
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Figure 2. The rules for a PTS X(S,A,TZ) 


example, in System F, a (*, *) product has the form nx : A. B, 
where x ranges over terms and A and B are types. Since System 
F does not include dependent types, x cannot occur free in B, so 
nx : A. B can be written A —> B. 

To demonstrate the uniformity of PTS syntax, consider the 
System F term Aa. Ax : a. x which has the System F type 
Va.a —¥ a. The symbol A denotes a type abstraction. The type 
variable a is not classified, since System F does not classify types. 
The symbol A denotes a term abstraction, and the term variable 
x is classified. The universal quantifier V forms the types of A 
abstractions, and —> forms the types of A abstractions. In PTS 
syntax, the term is written Aa : *. Ax : a. x, and the type is 
written Ila : *. Fix : a. a. Here the same symbol A is used for the 
both abstractions, and the type of each A abstraction is a product. 
Since x does not occur free in a, we can also write the type as 
Ila : *. a —4 a. 

Theorem 2.1 (Subject Reduction for -t-p v [15]). IfF b A : B and 
A A', then T b A' : B 

Theorem 2.2 (Church-Rosser for —»p [15]). If T b A : B and 
A -»p Ai and A -»p A2, then there exists A' such that Ai -»p A' 
and A2 -»p A'. 

While the focus of this paper is primarily on System U, we 
also discuss Systems F, F w and F+. The PTS specification of 
each system is listed in Figure 3. The sorts of each is a subset 
of {*, □, A}. We divide the legal expressions of each PTS based 
on these sorts: the sort * corresponds to the terms, the sort □ 
corresponds to the types, and the sort A corresponds to the kinds. 
More precisely, suppose a legal expression A is derived by T b A : 
B. If T b B : *, then A is a term. If T b B : □, then A is a type. 
If T b B : A, then A is a kind. 

The axioms A of a PTS instance defines how the different sorts 
are related to each other. The axioms of each PTS instance listed 
in Figure 3 are a subset of {* : □ : A}. The axiom (* : □) 

means that □ is the classifier of * and that types classify terms. The 
axiom (□ : A) means that A is the classifier of □ and that the 
kinds classify types. We call the classifier of a term its type, and the 
classifier of a type its kind. 

The rules TZ determine which products are legal in a PTS in¬ 
stance. The rules 7 Z of each PTS instance listed in Figure 3 are a 


subset of {(*, *), (□, *). (□, □), (A, *). (A, □)}. The rule (*, *) 
derives terms that abstract over other terms, the types of which 
are (*, *) products. The rule (d, *) derives terms that abstract over 
types, the types of which are|pfi:*) products. The rule (D|®de- 
rives types that abstract over other types, the kinds of which are 
(□, □) products. The rule (A,*) derives terms that abstract over 
kinds, the types of which are (A, *) products. The rule (A, □) de¬ 
rives types that abstract over kinds, the kinds of which are (A, □) 
products. 

In each PTS of Figure 3, legal products are either types or kinds. 
A product type is a legal product that is a type. It is necessarily a 
(s, *) product. A product kind is a legal product that is a kind. It is 
necessarily a ( s , □) product. 

We adopt a naming convention to help distinguish between 
terms, types, and kinds. Names starting with lower-case letters such 
as e refer to terms. Names starting with upper-case letters and the 
greek letters a, fj, r, and a refer to types. Greek letters k and x 
refer to kinds. 

Systems F and F^ are part of the A-cube [5], while F+ and U are 
not because of the rules (A, *) and (A, □). All except System U 
are strongly normalizing. Girard’s thesis [16] proved that System 
U is not strongly normalizing. In particular, there exists a legal 
term in System U with the type Ila : *.a that does not have 
a normal form. However, the types and kinds of System U are 
strongly normalizing. 

Type checking is decidable for each of System F, F w , F+, and U 
[6], This relies on that each system is injective [14], a technical 
property of Pure Type Systems. An injective PTS also has the 
property that types are unique [5]. 

None of the PTS instances shown in Figure 3 have dependent 
types (e.g., types that abstract over terms), which require the rule 
(*, □). A consequence of this is that any (*, *) product nx : n. T2 
can be written n —> T2. Types cannot depend on terms, so x cannot 
occur free in T2. 

3. System U 

In this section we define a decomposition of System U product 
types and use it to solve the Polymorphic Application problem for 
System U. The ideas in this section recur throughout the paper: in 
the definition of type representations in Section 4; in the decompo¬ 
sition of type representations in Section 4; and in the definition of 
term representations in Section 5. 

3.1 Decomposing Product Types 

In a pure type system, products are always classified by a sort. The 
sort of types is *, so product types are products classified by *. 





The product types of System U are formed by (*, *), (□,*), and 
(A,*). In general, if a product IIx : A. r is formed by (s, *), 
then r is classified by * (i.e. r is a type) and A is classified by 
s. System U products formed by (*, *) and by (A, *) are special 
cases. A (*, *) product of the form IIx : n .T2 is special because the 
bound variable x cannot occur free in T2 (i.e. types cannot depend 
on terms). Products formed by (A, *) are special because the only 
subject classified by A is □. 

Theorem 3.1. In System U, ifY b A : A, then A as 0. 

Proof. By induction on the height of the derivation. Assume T b 
A : A. We proceed by considering the last rule in the derivation. If 
the last rule is axioms, then (A : A) 6 A. The only possibility 
is (□, A), so A = □ as required. If the last rule is start, then 
(A : s) £ A. Contradiction. If the last rule is weakening, then 
T = Tj, x : C and Ti b A : A. By induction, A *|J|f as required. 
If the last rule is product, then there exist sorts si, S2 such that 
(.si, S2, A) £ Tl. Contradiction. If the last rule is abstraction, then 
A = IIx : A.B. Contradiction. If the last rule is application, then 
B[x := a] = A. There are two cases: either B = A, or a = A. 
If B = A, then (IIx : A. A) must be legal. This in turn requires 
a sort s and an axiom A : s. Contradiction. If a = A, then there 
must exist a term A such that T b A : A. Contradiction. If derived 
by conversion, then there must exist a sort s such that T b A : s, 
which in turn requires an axiom A : s. Contradiction. □ 

In words, Theorem 3.1 states that System U does not include 
a “type system” for kinds. The situation is similar for the types of 
System F, as it does not include a kind system (which is a “type 
system” for types). In the PTS formulation of System F, the only 
subject classified by □ is *. As we will see, Theorem 3.1 is a key 
property of System U that enables self-representation. 

Theorem 3.2. IfY b r : *, and t is a normal form, then r is of 
one of the following forms: 

a A\ ... A n where a is a type variable, 

n —» T2 where T b n : * 

Ila : k. Ti where r b k : □ 

IIx : Ti 

Since we are only interested in decomposing product types (and 
not applications of the form an ... r„), we only consider the 
last three cases. We begin by defining a constructor for each case 
of product, corresponding to the rule ( s , *) that forms the product. 
Definition 3.1 (Constructors for product types). We define the 
following constructors for product types: 

it* = Xa : X/3 : a /3 

tt D = Ax : Aa : x ^ *-II/3 : X- a /? 

7Ta = Aa : □ —> *.Yl X : a x 

It is straightforward to check that the product type constructors 
have the types given by the following judgments: 

0< : *^*^* 

0 b 7T D : IIx : (x -A *) -A * 
ft "A : (- > *) > * 

Every product type formed by (s, *) can be equivalently expressed 
as an application of the constructor tt, . This is akin to a higher order 
abstract syntax encoding of product types [30]. 

Theorem 3.3 (Decomposition of product types). For any legal 
(*, *) product n —» T2, any legal (□, *) product Ila : k. t, and 
any legal (A, *) product IIx : n we have: 

Tl -A T2 It* Tl T2 

Ila : k. t Tta k (Aa : k. t) 

nx : O.T =p tta (Ax : t) 


Below we define the components of a product to be the argu¬ 
ments of the constructor that yield an equivalent type. 

Definition 3.2 (Components of products). 

• The components of a (*, *) product type tl —T 2 are n and 
T2. 

• The components of a (□, *) product type Ila : k. t are n and 

• The component ofa (A,*) product type IIx : □■fisAx : D-r. 
The following theorem states that the components of a product 

are always legal in the same environment as the product itself. 
Theorem 3.4 (Types of product components). 

1. If T b (IIx : n. T2) : * and F b Ti : *, then r b T2 : *. 

2. If T b (Ila : k. t) : * and Y b k : □, then 
Y b (Aa : k . t ) : k -A *. 

3. If Y b (nx : □. t) : *, then Y b (Ax : □. r) : □ —S- *. 

As stated earlier, the key properties of System U that enable our 
self-representation technique are that product types can be decom¬ 
posed, and that terms and types can abstract over the components. 
The components of a (*, *) product are two types, and can be ab¬ 
stracted in terms and types by the rules (apy and (□,□), respec¬ 
tively. The components of a (□, *) product are a kind and a type, 
and can be abstracted in terms by the rules (A, *) and (□, *), and 
in types by (A, □) and ®|p). The single component of a (A, *) 
component is a type, and can be abstracted over in terms and types 
by (□,*) and (□, □). These properties will play key roles in our 
solution of the Polymorphic Application problem (Section 3.2), and 
in the representation of types (Section 4) and terms (Section 5). 

3.2 Polymorphic Application 

We can now formalize the requirements of a polymorphic applica¬ 
tion functions and state the Polymorphic Application problem for a 
class of Pure Type Systems. 

Definition 3.3 (Standard PTS). A PTS A(5, A, Tl) is standard if: 

• The designated sort * £ S classifies the types of terms. 

• For each sort s £ S, (s : *) 0 A 

• If{si, S2, *) € 'll, then S2 = *. 

The first condition of a Standard PTS establishes * as the sort 
corresponding to terms. The second condition states that terms do 
not classify anything. The third condition states that if a term is 
an abstraction, then its body is also a term. The systems listed in 
Figure 3 and those in the A-cube are all standard. 

Definition 3.4 (Polymorphic Application Function). Let A(S, A, 'll) 
be a Standard PTS, let (s, *) £ Tl, and letp be a legal closed term. 
We say that p is a polymorphic application function for the (s, *) 
products ofX(S, A, 'll) if it satisfies the following two conditions: 

• p is of the form 

Axi : Ai. ... Ax n : A n . Ax : (II61 : B.t). A62 : B. x 62 
for some xi, ... x„,A 1, ... A n ,bi,b2, B,r such that 
xi : Ai,... ,x„ : A n b B : s. 

• For every closed (s, *) product o of X(S, A, Tl), there exist 
legal expressions ai,... ,a„ such that 

() b p ai ... a„ : 0 cr 

The first condition defines the form of a polymorphic applica¬ 
tion function for (s, *) products. The n outermost abstractions are 
what make it polymorphic: they abstract over the component(s) 
of such products. The term under the n outermost abstractions, 





Xx : (II&i : B. t). A62 : B. x 62, should be an application function 
for an arbitrary (s, *) product. The second condition states that we 
can obtain an application function for particular closed ( s , *) prod¬ 
uct by n applications. 

Definition 3.5 (Polymorphic Application Problem). For a Stan¬ 
dard PTS X (S, A, 1Z), we say that X (<S, A, 1Z) supports polymor¬ 
phic application if there exists a legal polymorphic application 
function polyapp* for every rule (s, *) € 1Z. 

For example, a solution of the Polymorphic Application prob¬ 
lem for System F requires two polyapp functions that are legal Sys¬ 
tem F terms: a polyapp* function to apply terms to terms, and a 
polyapp n function to apply terms to types. We conjecture that no 
legal polyapp n function exists for System F, and therefore that the 
Polymorphic Application problem for System F is impossible. 

We now show how to solve the Polymorphic Application prob¬ 
lem for System U. The solution consists of three application func¬ 
tions: polyapp*, polyappa, and polyappA. Later we will use the 
techniques from this section to define our representations of types 

Term applications. Our first polymorphic application function 
polyapp,, applies terms to terms. Terms that can be applied to 
other terms have (*, *) product types of the form n —T2, where 
() h n : *. An application function for terms of type n —» T2 will 
have the type (n —> T2) —tn—t T2, and can be implemented as: 

Af : n —>• T2 . Aa : n. f a 

By Theorem 3.4, we have that ()• T? : *. Therefore, we can 
make this polymorphic by abstracting out n and T2. The resulting 
function, polyapp*, implements application of (*, *) functions: 

polyapp* = An : *. Xt 2 : *. Af : n —» T2. Aa : n. f a 
The abstractions of n and T2 are type abstractions formed by 
*). The type of polyapp* is: 

Iln : *. IIt 2 : *. (n -+ r 2 ) ->n ->■ T2 
Lemma 3.1. polyapp* is a polymorphic application function for 
(*, *) products in System U. 

Proof We have already seen that polyapp* is legal. It is easily 
checked that it has the required form, and that n : *,r2 : * P 
n : *. Let <n —y <72 be closed a (*, *) product in System U. By 
Theorem 3.4, the components <n and 02 are both closed types of 
kind *. Therefore polyapp* <71 02 : (<n —» <72) —» oi —> 02 as 
required. □ 

Type applications. Our second polymorphic application func¬ 
tion polyapp n applies terms to types. Terms that can be applied to 
types have (□, *) product types of the form Ila : k. t, where a 
ranges over types of kind k and r is a type. Based on the type rules 
in Figure 2, an application function for terms of a particular (□, *) 
product type Ila : k. t should have the type: 

(na : K.T) -A up : k. (r[o := 0\) (t) 

Here r[a := 0] denotes the type obtained by substituting 3 for a 
in t. The syntax r[a := /3] is not part of our language of types, but 
can be expressed as (Aa : k. t) /3. Letting r' denote Aa : k. r, we 
can write (f) as: 

(na : n. t' a) -> Up : «. r' /3 

We can implement a polymorphic application function polyapp n 
for (□,*) products by abstracting over k and r\ which are the 
components of na : n. r. Theorem 3.4 states that k has sort □ and 
t' has kind 

polyapp n = Xk : D-At' : n -¥ *.Af : (na : k. r'a).X/3 : n. f /3 


The first two abstractions of polyapp n bind the components of an 
arbitrary (□, *) product type. The third abstraction binds a term of 
the corresponding product type. The final abstraction binds the type 
argument. The type of polyapp n is: 

n/t : □. nr' :/«—>■*. (na : k. t a) —¥ n/3 : k. r ft 
Lemma 3.2. polyapp n is a polymorphic application function for 
Bi *) products in System U. 

Proof. We have already seen that polyapp n is legal and has the 
required form. It is easily checked that k : a, t' : k —^ * h k : □. 
Let (na : K1.0) be a closed, legal (□, *) product in System U. 
Then n 1 is closed and classified by □. By Theorem 3.4, we have 
that (Aa : ni. cr) is closed and has kind ki —*. It is easily 
checked that we can derive () h polyapp n k\ (Aa : k,i . <7) : (na : 
K\. <7) —» (na : Ki. cr), as required. □ 

Kind applications. Our last polymorphic application function 
polyapp A applies terms to kinds. Terms that can be applied to types 
have (A, *) product types of the form nx : □. r, where x ranges 
over kinds and r is a type. An application function for terms of a 
particular (A, *) product type nx : □. r should have the type: 

(Dxi : □•t) -A 11x2 : D-rlxi := X2] (J) 

This type is similar to (f), with one important difference: whereas 
the type variables a and 3 are classified by an arbitrary kind k, the 
kind variables xi and X2 can only be classified by □ (by Theorem 
3.1). We express the substitution as (Axi : r) X2- Letting t' 

denote Axi : □. r, we can write (1) as: 

(nxi : r' Xi) ->■ 11x2 : T X2 
Theorem 3.4 states that t has kind Therefore, we can 

implement a polymorphic application function for (A, *) as: 

polyapp A = At' : *. Ax : (nxi : Q. T Xi)- ^X2 : x X2 

The first abstraction of polyapp A is a type abstraction that binds the 
sole component of an arbitrary (A, *) product type. The second 
abstraction binds a term of the corresponding product type. The 
final abstraction binds the kind argument. The type of polyapp A is: 

polyapp A : nr' :□->■*. (nxi : □. t xi) -A nx2 : t X2 
Lemma 3.3. polyapp A is a polymorphic application function for 
(A, *) products in System U. 

Proof We have already seen that polyapp A is legal and has the 
required form. It is an axiom of System U that □ is classified by 
A. Let (nx : A. <7) be a closed, legal (A, *) product in System U. 
Then A is closed and classified by A. By Theorem 3.1, A = □. 
By Theorem 3.4, we have that (Ax : □. <7) is closed and has kind 

□ —> *. It is easily checked that we can derive {) F polyapp A (Ax : 

□ . a) : (nx : □• <7) —» (nx : □. ff), as required. □ 

It is notable that the definition of polyapp A uses every rule of 
System U. The abstractions over x, r', and X2 are formed by (*,*), 
(□, *), and (A, *), respectively. The type constructor 7 ta is type- 
level function formed by (□,□), and the kind □ —> * of r' is 
formed by (A, □). 

Theorem 3.5. System U solves the Polymorphic Application Prob- 

Proof Lemmas 3.1, 3.2, and 3.3 show that there exist legal poly¬ 
morphic application functions in System U for each of its (s, *) 
rules: (*,*),(□,*), and (A, *). □ 

Our polyapp functions we rely on two properties of System U: 
that we can decompose product types (Theorem 3.3), and that □ is 
the only subject classified by A (Theorem 3.1). System U appears 
to be a local minimum (excluding the trivial PTS with 1Z = 0): 
each of the rules (*, *), (□,*), (□, □), (A, *), (A, □) is important 
for our solution. 



(*,*) 

System F / 

System F w / 

System F+ / 

System U / 


(□>*) ( A ,*) 


/ x 

/ / 


Table 1 . Polymorphic application functions in our PTSs. 


3.3 Polymorphic application in other systems 

That □ is the only subject classified by A is a key to solving the 
Polymorphic Application problem for System U: it avoids the need 
to abstract over 33^ which is impossible in System U. However, 
there is more to the story - in System F, * is the only subject clas¬ 
sified by □, and yet it appears that Polymorphic Application is im¬ 
possible in System F. The question of whether a PTS supports Poly¬ 
morphic Application seems to require whole-system consideration. 
We do not know of a simple test that can answer this question for 
an arbitrary PTS, and leave the formulation of such a test for future 

We conjecture that Polymorphic Application is not possible 
for System F, F w , or F+. Table 1 summarizes the polymorphic 
application functions that can be implemented in each system using 
the techniques of Section 3.2. Cells marked with / indicate that a 
polyapp s function for (s, *) products can be defined in the system. 
Cells marked with x indicate that the definition of polyapp s in 
that system seems to be impossible. Empty cells indicate that (s, *) 
products are outside the system. 

The first column shows that polymorphic application functions 
for (*, *) products can be implemented in all four languages. This 
is because a (*, *) product can be decomposed into two types of 
kind *, and each language includes terms that abstract over types 
of kind * via the (□, *) rule. 

System F does not support a polyapp n function for applying 
terms to types. In System F, decomposing (□,*) products (i.e. 
quantified types) requires higher-order types, which in turn require 
the rule (□, □). 

System F w can implement a polymorphic application function 
for System F (□, *) products, but not for its own (□, *) products. 
Since all System F types have kind *, all (□, *) products in System 
F have the form Ha : r. These can be decomposed into a single 
component A a : *. r, which has kind * —S> * in F w . Since F w 
includes higher kinds, a polyapp n function for F„ should abstract 
over the kind, as we did in the polyapp n for System U. Since F w 
does not include the rule (A, *) needed for kind abstraction in 
terms, it cannot implement polyapp n . 

System F+ can implement polyapp D because it includes the 
rule (A, *). However, it can’t implement polyappA because (A, *) 
product types can’t be decomposed in F+. Decomposing (A,*) 
products requires kind-polymorphic types, which in turn require 
the rule (A, □). 

The techniques used to implement these polymorphic applica¬ 
tion functions can also be used to build typed representations. Thus, 
we can interpret the results of Table 1 to mean: System F can be 
represented in F w , F w can be represented in F+, F+ can be repre¬ 
sented in U, and U can be represented in itself. In sections 4 and 5 
we will use the techniques from this section to build representations 
of types and terms. 

4. Representing Types 

In this section, we define a process for representing types of kind *. 
Type representations are themselves types. We are primarily inter¬ 
ested in term representations, and the purpose of type representa¬ 
tions is to enable more typed operations on term representations - 


in particular, operations like CPS transformation that transform the 
type of a program in a non-trivial way. 

Since the purpose of type representations is to support typed 
operations on term representations, we only represent types of kind 
*, which are the types of terms. We do not represent higher-order 
types like A a a, which has the kind * —> *. We only represent 
types in normal form - products, variables, and applications of 
variables to one or more types. While the terms of System U are not 
strongly normalizing, the types are. This ensures that any type of 
kind * can be normalized and represented. While we only represent 
closed terms, it is important that we can represent open types. This 
is because we will represent not only the type of the top-level term 
being represented, but also the type of each of its subterms. Type 
representations should support type functions that depend on the 
intensional structure of their inputs. These play an important role 
in the implementation of our typed CPS transformation in Section 
6.3. We summarize the requirements for our representation of types 

Definition 4.1. The requirements for our type representation pro¬ 
cedure are: 

• Only legal types can be represented. 

• Every legal normal-form type of kind * can be represented. 

• Type representations support operations that fold over the 
structure of the type. 

Constructors for Type Representations. We represent types 
using higher order abstract syntax (HOAS), inspired by [27] and 
[30]. Type representations are types of kind U, which is defined 
inductively from four constructors. Theorem 3.2 states that a type 
of kind * is either an application of a type variable to zero or more 
arguments, or a product derived from one of the rules (*,*), (□,*), 
or (A, *). Our type representation includes a constructor for each 


Definition 4.2 (Constructors of Type Representations). The kind U 
is defined inductively by the constructors: 

• Var : * -4’U 
0 F Prod* :U-tU4U 
0 h Prod D : (n X : □. U) -4 U) 

() F Prod A : (□ —> U) —> U 

The constructor Var builds representations of type variables 
applied to zero or more types. The constructors of Prod*, Prod n and 
ProdA build representations of (*, *), (□, *) and (A, *) products, 
respectively. Their types are similar to those of the constructors 7r*, 
7r n , and 7 ta defined in Section 3.1, except that they construct types 
of kind U instead of types kind *. The body of this paper will keep 
the definitions of U and its constructors abstract. The appendix of 
the full paper gives concrete definitions of U and its constructors as 
System U terms. 

Building Type Representations. The procedure > for build¬ 
ing type representations is defined in Figure 4. It takes as input the 
derivation of a normal form type of kind * and outputs a represen¬ 
tation of the type. The representation of a product type depends on 
whether it is a (*, *) product, a (□, *) product, or a (A, *) product. 

An application of a variable to zero or more types is represented 
by applying the constructor Var to it. A product formed by (*, *) 
has the form n —> T2, where n and 72 are each of kind *. It is rep¬ 
resented by applying the constructor Prod* to the representations 
of n and 72. A product formed by (□, *) has the form Ha : k. t, 
where r has kind * and a may occur free in r. We build the rep¬ 
resentation of r in the environment r, a : k, and abstract over a 
in the representation a. The result has kind n —» U in the envi¬ 
ronment r. We then apply the constructor Prod n to the kind k and 
the resulting abstraction. A product formed by (A, *) has the form 



UId = Fold[(Aa : *. a), 7r», 7r n , 7 ta] 


r h a Ai ... A n : * > Var (a Ai ... A n ) 


r I- Tl : * > <71 r h T2 : * > <72 

r h n —> T2 : * > Prod* <7i <72 

T h k : □ F,a : k\~ t : * > a 
r h (n« : k.t) : * > Prod n k (Aa : rt.o) 

_ r,x:Dl--r:*>cr _ 

T h (n X : D.r) : * > Prod A (A X : □ .<r) 


Figure 4. Type Representation Procedure 


n X : r, where r has kind * and \ may occur free in r. We 

build the representation of r in the environment T. X : □, and ab¬ 
stract over x in the representation a. The result has kind □ —» U 
in the environment T. We then apply the constructor Prod a to the 
resulting abstraction. 

Theorem 4.1 (Kinds of type representations). If T b r : * and 
W t:*> a, then Pf*.<7 : U. 

Example 4.1. The type of the polymorphic identity function, Ila : 
*.a —> a, is represented as Prod n * (Aa : *.Prod* (Vara) (Vara)). 

When context T of the derivation T h r : * is clear, we write r 
to denote the type a such that T h r : * > <7. 

Folds over type representations. Our type representation en¬ 
ables operations that fold over the structure of the type. A fold is 
defined by supplying case functions for each case of the structure 
of types of kind *: variables (or type applications with a variable 
in function position), (*, *) products, (□, *) products, and (A, *) 
products. 

Case functions for type variables have kind * —» *. Variables 
are the base case for our inductive type representation. The fold 
function maps an input variable to some type of kind *. Since we 
only represent types of kind *, the input type variable must have 
kind *. Case functions for (*, *) products of the form n —y 72 
have kind * —>■ * —>■ *. Its two arguments of kind * correspond 
the results of folding over n and 72. Case functions for (□,*) 
products of the form Ila : n. t have kind Tlx : □. (x —1 *) —1 *. 
An argument type of kind (x —T *) will be the result of folding 
over a type in which a type variable of kind x can occur free. Case 
functions for (A. *) products of the form Fix : 7 have kind 

‘Ifp —>- *) —I *. An argument type of kind (c -»• *) will be the 
result of folding over a type in which a kind variable can occur 
free. 


Definition 4.3. Suppose 


() h prod, 
() I- prod c 
() I- prod z 


r, prod,, prod n , and prod A satisfy: 


nx:n.(x-f*)-f* 

(□-►*)-+* 


Then Fold [var, prod,, prod D , prod A ] denotes the type F such that 
() I- F : U *, and: 

Vr=p var 7 if 7 is of the form a Ai ... A n 

F 7 =p prod, (F tl) (F vf) if 7 = T\ —* 72, T h 7i : * 

F 7 =p prod n k (Aa : k. F tT) if 7 = Ila : k.7i , r h k : □' 

Ffs^ prod A (Ax : □. F 7f) if 7 = Fix : □. 7i 


Our first example of an operation on type representations is 
listed in Figure 5. UId recovers a type from its representation. The 


Figure 5. A function that recovers a type from its representation 


case function for variables is the identity. The case function for each 
product type is the corresponding constructor. 

Theorem 4.2. If T h 7 : *, then UId 7 =g r. 

We define the components of type representations similarly to 
the components of types: 

Definition 4.4 (Components of product representations). 

• The components of the representation of a (*, *) product type 
n -» 7 2 are n and fj. 

• The components of the representation of a (□, *) product type 

, k. 7 are n and A a : k. t. 

• The component of a (A.,*) product type Tlx '■ U.ris\\ '■ D.7. 

5. Representing Terms 

In this section we define a process quote(-) that builds representa¬ 
tions of terms. We begin by establishing the requirements for our 
representation. First and foremost,we should be able to represent 
every legal term in the language, and representations should them¬ 
selves be legal terms. All representations should be strongly nor¬ 
malizing, even if they represent a non-normalizing term. In order 
to be considered useful, we require our representations to support 
operations that fold over the structure of the term. We summarize 
our requirements typed representation of terms below. 

Definition 5.1 (Requirements for term representation). 

• Only legal terms can be represented. 

• Every closed legal term can be represented. 

• All representations are strongly normalizing. 

• Representations support folds. 

Given these requirements, what is required to type check repre¬ 
sentations? Since a representation has different semantics than the 
term it represents, we expect its type to also be different. On the 
other hand, we expect the types of a term and its representation 
to be related. This allows typed operations with result types that 
depend on the type of the input term. 

5.1 Representation using PHOAS 

We represent terms using typed Parametric Higher Order Abstract 
Syntax (PHOAS) [12, 35]. The use of PHOAS allows our repre¬ 
sentation to support multiple operations with different result types. 
Recall that our type representation, which uses a simpler non- 
parametric HOAS, only supports operations that produce results of 
kind *. In each case we choose the simplest representation for our 

Our representations have types of the form Exp 7, where 7 is 
a type representation. The type Exp is defined in Figure 6. It is 
parametric in a type R of kind U —> *, which is supplied by 
each operation and determines the result type of the operation. 
Instantiating a representation of type Exp 7 with a result type R 
yields the type PExp R 7, which can be read “Exp 7 specialized to 
parameter R”. 

The specialized representation type PExp is inductively defined 
by the constructors listed in Figure 6. There is a constructor for each 
form of the terms of System U. System U terms are either variables, 
A abstractions, or applications. The abstractions and applications 
can be formed by the rules (*, *), (□, *), or (A, *). 

Our quotation procedure quote(-) is defined in Figure 7. It relies 
on a pre-quotation procedure ► defined in Figure 8. Given a term 



mkVar : IIR : U —» *. Ha :U.Ra-> PExp R a 

mkAbs* : IIR : U -)• *. Ila : U. U/3 : U. 

(Ra-J PExp R 0) -» PExp R (Prod, a 6) 

mkApp* : nR : U -> *. Ua : U. U/3 : U. 

PExp R (Prod, a 0) -S- PExp Ra^ PExp R $ 

mkAbsn : IIR : U —¥ *. IIk : □. Ila : (k —> U). 

(n 3 : k. PExp R (a /?)) '->• PExp R (Prod a k a) 

mkApp n : IIR : U —¥ *. II« : □. Ila : (k —¥ U). 

PExp R (Prod n k a) —> II/3 : k. PExp R (a 3) 

mkAbsA : IIR : U —» *. Ila : □ -»• U. 

(U X '■ PExp R (a x)) '<-* PExp R (ProdA a) 

mkApp A : IIR : U —> *. Ila : □ -¥ U. 

PExp R (Prod A a) IIx : PExp R (a x) 


Exp = Aa : U. IIR : U —> *. PExp R a 


Figure 6 . Representation Constructors 


() E e : r ► g 
quote(el#%» A R : U —> *. q 


Figure 7. Quotation 


of type r, the pre-quoter produces a term of type PExp R t. Then 
quote(-) simply abstracts over R in the result. 

The pre-quoter embeds type representations within term rep¬ 
resentations. This is a key to supporting operations like CPS that 
transform the type of their input. As is common in HOAS repre¬ 
sentations, we use abstractions to bind the free variables of a rep¬ 
resentation. For example, if a : k E e ► q, then a may occur free 
in q. We close q by abstracting over a. If q has type PExp R r, 
then Aa : K.q has type Ila : k. PExp R r. This reflects that the 
representation has a free variable, and enables substituting for a by 
application. 

The first rule of pre-quotation handles variables. Representa¬ 
tions of variables are constructed using mkVar. Variables are rep¬ 
resented metacircularly [28], that is, using other variables. In par¬ 
ticular, a variable of type r is represented using a variable of type 
Rr. 

Abstractions formed by (*, *) bind term variables in terms, and 
have types of the form n — > T2. Their representations are con¬ 
structed using mkAbs*. The types t! and T2 are the components of 
f\ -A T 2. The premise T, x : n E e : T2 ► q builds a representation 
of the body in the extended environment T, x : n. The abstraction 
AxiRn.q binds the free variable x in the representation of e. 

Applications formed by (*, *) apply terms to terms. An appli¬ 
cation ei C2, where ei has the type T2 —> r, is represented by ap¬ 
plying the constructor mkApp t to the components of T2 —> r, and 
the representations of ei and e2. 

Abstractions formed by bind type variables in terms, 

and have types of the form Ila : k. t. Their representations are 
constructed using mkAbs D . The kind k and type A a : k. t are 
the components of Ila : k. t. The premise T, a : K h e : r ► q 
builds a representation of the body in the extended environment 


T h t : * _ 

T h a; : r ► mkVar Rfi 

T h n : * T, x : ti h e : T2 ► q 
T h (Aa; : n.e) : n — > T2 ► mkAbs, R tTt 2 (Aa; : Rri.q) 

T h T2 : * T \- ei : T2 —> r ► qi T h e2 : T2 ► g2 
T h ei e 2 : r ► mkApp* R Ti r qi qi 

T h /t : □ T, a : k \~ e : t >■ q 
T h (Aa : K.e) : (na : k.t) ► mkAbs D R k (Aa : k.t) (Aa : K.q) 

r I- K : □ r h e : ( na : k.t) ► q 

_ (r[a := n]) (r[a := nj) = c _ 

Then: (r[a := n]) ► c (mkApp n R k (Aa : k.t) q n) 

_ r,x:al~e:r>-g _ 

r h (Ax : a.e) : (nx : D.r) ► mkAbsA R (Ax : D.r) (Ax : D.g) 

_ T E e : (n X : D.r) ► q _ 

T E e k : (t[x := «]) ► mkApp A R (Ax : O.t) q k 


Figure 8 . Pre-quotation 


T, a : k. The abstraction A a : K. q binds the free variable a in the 
representation of e. 

Applications formed by (&■#) apply terms to types. Only the 
term is represented; the type argument is not represented, even if it 
is of kind *. The constructor mkApp n is applied to the components 
of the no : k. t, the representation q of the term e, and the type 
argument t\. The result is a term of type PExp R r[a := T\\. A 
coercion c of type PExp R (r[a := n]) —> PExp R (r[a := n]) 
is generated by the binary operation Coercions are discussed 
further below, and full detail is given in the appendix to the full 

Abstractions formed by (A, *) bind kind variables in terms, 
and have types of the form IIx : □. r. Their representations are 
constructed using mkAbsA • The type Ax : □. r is the component 
of IIx : t. The premise V, \ : Cf E e ; r ► q builds a 
representation of the body in the extended environment T, x : 
□ . The abstraction Ax : □. q binds the free variable x in the 
representation of e. 

Applications of products formed by (A, *) apply terms to kinds. 
Again, only the term is represented. The constructor mkApp A is 
applied to the component of Ux : the representation of the 

term, and the kind argument. 

Example 5.1. Let id = A a : *.Xx : a.x. 

quote(id) =AR : U —> *. 

mkAbs : R * (Aa : *. a —Ea) 

(Aa : *. mkAbs, Raa 

(Ax : R a. mkVar R a x)) 

In bottom-up order, the mkVar term corresponds to the output 
of the pre-quoter ► on the derivation a : *, x : a E x : a, the 
mkAbs* term to the output on a : * E (Ax : a. x) : a —t a, and 
the mkAbsn term to the output on (} E id : (Ila : *.a —> a). At 
the top-level, quote(id) abstracts over R in the pre-quotation of id. 

For convenience, we define a notation e as we did for type 
representations, though its definition is slightly different. When e 




is a term, e denotes its pre-quotation, which allows us to use e even 
when e is not closed. 

r h e : t ► q () h F : U -> * 
e = g[R:=F] 

We allow the environment T and the result type function F to be 
implied hy the context. 

Since variables are represented by variables with different types, 
we define a representation environment T in which pre-quotations 
are legal. We define V inductively by the following rules. We allow 
the result type function F to be implied by context. 

Definition 5.2 (Representation Environment). 

fe i 

r,x : t = r,x : Ff ifTF-r:* 

F,a: K =T,a: k if F, F k : □ 

F,X :'S.= 

We now formalize the types of pre-quotations and quotations: 
Theorem 5.1. If T F e : r and () F F : U —k *, then 
e : PExp F r. 

Theorem 5.2 (Types of quotations). If () : r : *, and 

quote(e) — q, then () hq: Exp r. 

Theorem 5.3. If quote(e) = q, then q is strongly normalizing. 

Authors traditionally define a representation in A-calculus to 
be a normal form [22, 23, 27]. We follow Pfenning and Lee [26] 
and define constructors for our representation, which allow us to 
abstract away the details of our encoding. Representations built 
from our constructors are not normal forms, but reduce to normal 
forms in a few predictable steps. We provide an example in the 
appendix to the full paper [1], It is also possible to define a quoter 
that produces closed normal forms. 

5.2 Tying the knot 

Theorem 5.2 states that our quotation procedure is complete: ev¬ 
ery legal System U term can be represented. We achieve self¬ 
representation using the techniques developed for our solution to 
the Polymorphic Application problem in Section 3.2. The type of 
each polyapp, function is related to the types of the corresponding 
representation constructors mkAbs, and mkApp,. 

Each polymorphic application function polyapp, abstracts over 
the components of (s, *) product types. We can use UId to define 
a version of polyapp., that abstracts over the components of (s, *) 
type representations. For example, polyappA could be defined as: 

Aa : □ -k U. Ax : UId (Prod A a). Ax : □. x x 
The application of x to x is legal because UId (Prod A a) is 
equivalent to IIxi : □. UId (a xi). This version of polyapp A can 
have either of the following equivalent types: 

• Ila : □ -k U. (IIx : □. UId (a x)) UId (Prod A a) 

• Ila : □ -k U. UId (Prod A a) -k IIx : UId (a x) 

If we replace UId with PExp R in the first type and abstract over 
R, we get the type of mkAbs A . The same operation on the second 
type yields the type of mkApp A . 

We summarize the results of Section 3.2, Section 4, and Section 
5 as follows: Every form of product type in System U can be 
decomposed, and we can implement a polymorphic application 
function by abstracting over the components. Further, every form of 
product type in System U can be represented. Type representations 
can also be decomposed and the components can be also used to 
define a polymorphic application function. Finally, we can combine 
our polymorphic application functions with standard representation 
techniques to achieve self-representation. 


Abs, = AR : U —k *. Ila : U. II/3 : U. 

(RaARj3)->R (Prod, a P) 

App, = AR : U -k *. Ila : U. II/3 : U. 

R (Prod, a/3)-kRa-kR£ 

Abs n = AR : U -k *. IIk : □. Ila : (kt -k U). 

(Up : kt. R (a p)) —k R (Prod D kt a) 
App D = AR : U —k *. IIk : □. Ila : (kt —k U). 
R (Prodo kt a) —k UP : kt. R (a p) 

Ahs A = AR : U —k *. na : □ —k U. 

(IIx : R (a X)) ->• R (ProdA a) 
App A = AR : U —k *. Ila kU. 

R (ProdA a)-k n X : R (a x) 


Figure 9. Types of Case Functions 


5.3 Folds over term representations 

Our representation of terms is designed to support operations that 
fold over the structure of the term. A fold is defined by six case 
functions, one each for abstractions and applications formed by 
(*, *), (□,*), and (A, *). The result of a fold is defined by induc¬ 
tion on the structure of the term. For each term, the corresponding 
case function is applied to the the results of folding over its sub¬ 
terms. This is made formal below. 

The types of the case functions of a fold are defined in 9. 
The types App„, App a , and App A and are similar to the types 
of our Polymorphic Application functions polyapp,,, polyapp n and 
polyapp A from Section 3.2. Each App, types and the type of 
each polyapp, function relies on the idea of decomposition. The 
difference is that the App, types deal with components of type 
representations, while the types of the polyapp, functions deal with 
components of product types. 

The specification of an operation on term representations con¬ 
sists of a result type R, a witness of type Witness R, and six case 
functions. The witness ensures that for all types r and n such that 
r, a : kt F r : * and r h Ti : kt, the quoter can synthesize a coer¬ 
cion of type: PExp R (r[a := n]) -k PExp R^jaa := Ti}). These 
coercions are necessary in order to represent type applications. The 
semantics of a coercion thus depends on the witness, which gives 
us the flexibility needed to support multiple operations on a single 
generic representation. We will say more about the coercions for 
each of our operations in the following section. Witnesses and co¬ 
ercions are described in greater detail in the appendix to the full 

Definition 5.3. Suppose F, w, abs,, app„, ahs D , app D , abs A , and 
app A satisfy: 

(>FF : U —k * 

() h w : Witness F 

() F ahs, : Abs, F {) F app„ : App„ F 

() F abs 0 : Abs n F () F app n : App n F 

() F absA : AbsA F | F app A : App A F 

Then fold[F, w, abs*, app*, abs a , app n , abs A , app A ] denotes a term 
f such that () F f : Ila : U.PExp F a —k F a, and for any context 
T, term e, and type r such that f F e : r, we have that: 



w : Witness UId 

id, = Aa : U. A/3 : U. Ax : UId a -A UId 0. x 

id D = Xk : □. Act : k -A U. Ax : (II/3 : k. UId (a /3)). x 

id A = Aa : □ -A U. Ax : (IIx : □. UId (a x))- x 

unquote = fold[UId, w, id,, id,, id D , id n , id A , id A ] 

Figure 10. Definition of unquote 


If e is a variable, then f r e =p e. 

If r = T i —>• T2, r h n : and e = Ax : n. ei, then 
fre =p abs, rf ¥5 (Ax : FfT. f75el). 

If e = ei e2, r F e2 : n : *, then 

fre =P app„ rfr (f n -4 ref) (frf ejj). 

If t = Ha : k. n, r F k : □, and e = A a : k. ei, then 

fre ahs D /t (Aa : k . ri) (Aa : k . frfef). 

If e = ei T2, T I- n : □, and Thei : Ila : K. n, then 
fremp c (app D k (Aa : K. n) (flla : k.Ti d) r 2 ) 
for some coercion c. 

If t = H X ; □. Tl, and e — A\- : □. ei, then 
fre ahs A (Ax : □■n) (Ax : f Tj ei). 

If e = ei k, T F k : □, and T h ei : IIx : □. Ti, then 

fre =g app A (Ax : n) (f IIx : □•Tt el) k. 

Definition 5.3 states that the operation specified by fold[F, w, 
abs*, app t , abs n , app n , abs A , app A ] has the semantics expected 
of a fold. The seven cases are mutually exclusive and exhaustive: 
a term in System U is either a variable, an abstraction, or an 
application. Abstractions and applications can be formed by one 
of three rules: (*, *), (□,*), (A, *). 

6. Operations 

In this section we show how to program three benchmark oper¬ 
ations on our representation. The first, called unquote, is a typed 
self-recognizer - a self-interpreter that recovers an term from its 
representation. The second, called isAbs, is a simple example of 
an intensional predicate. It tests whether its input represents an ab¬ 
straction or an application. The third, and most complex, is a typed 
self-applicable continuation-passing-style (CPS) transformation. 

6.1 Unquote 

Our self-recognizer unquote is defined in Figure 10. It produces 
results with types determined by UId. Each case function in the 
definition of unquote is an identity function. If a term e has type r, 
then unquoting a representation of e produces a term of type UId r. 
Theorem 4.2 states that UId r is equivalent to r. 

Theorem 6.1 (Type of unquote). 

(} r unquote : (Ila : U. Exp a -4 UId a) 

Unquote folds identity functions over the term. The result is 
equivalent to the original term. 

Theorem 6.2 (Correctness of unquote). 

If () F e : r and quote(e) = q, then unquote fqs^e. 

The coercions produced by the witness for unquote are al¬ 
ways identity functions. Consider the type UId (r[a := n]) —>• 
UId r[a := n], which is the type of an arbitrary coercion for un¬ 
quote. This type is equivalent to r\a := Ti] —> r[a := n], 

6.2 isAbs 

Our second benchmark operation isAbs is shown in Figure 11. 
isAbs tests if its input is a representation of an abstraction. This 
demonstrates that we can define operations on a representation that 


Bool = Ila : *. a -A a -A a 
true = Aa : *. At : a. A/ : a. t 

false = Aa : *. At : a. A/ : a. / 

UBool = Aa : U. Bool 

w : Witness UBool 

abs, = ATi : *. AT 2 : *. Af : Bool —> Bool.true 

app_ = ATi : *. AT 2 : *. Af: Bool. Aei : Bool, false 

abs D = A x : AF : x —> *• Aei : x —• y Bool, true 

app n = A x : AF : x —> *• Aei : Bool. Ax : x- false 

abs A = ATi :□—>•*. Aei : □ —l Bool, true 

app A = ATi :□—>•*. Aei : Bool. A x : D.false 

isAbs = fold[UBool, w, abs*, app t , abs n , app n , abs A , app A ] 

Figure 11. Specification of isAbs 


cannot be defined directly on the represented term. The result type 
UBool of isAbs is the constant Bool function. Each case function in 
the definition of isAbs is a constant function. It discards the result 
of folding over its subterm(s), since we are only interested in the 
outermost constructor of the representation. The case functions for 
abstractions are constant true functions and the case functions for 
applications are constant false functions. 

Theorem 6.3 (Type of isAbs). 

() F isAbs : (Ila : U. Exp a —> Bool) 

The application of isAbs to the representation of a term of type r 
produces a term of type UBool r, which is equivalent to Bool. Like 
those for UId, coercions for UBool types are identity functions. 
Consider the type UBool (r[a := n]) —¥ UBool r[a := n], 
which is the type of an arbitrary coercion for isAbs. Since UBool 
is a constant function, this type is equivalent to Bool —> Bool. 

Theorem 6.4 (Correctness of isAbs). 

If () F e : r : * and quote(e) = q then: 

• If e = \x : A.ei, then isAbs r q =p true. 

• Ife = ei A, then isAbs r q =,5 false. 

6.3 Continuation-Passing Style 

In this section, we implement a type call-by-name continuation¬ 
passing style (CPS) transformation on our representation. CPS 
transformation is commonly used in compilers for functional lan¬ 
guages. It makes the evaluation order (call-by-name in our case) 
explicit, and eliminates the need for a control-stack. There are ex¬ 
amples of typed CPS transformations in the literature, though ours 
is the first that is self-applicable. We extend the typed CPS trans¬ 
formation of [27], which operates on typed representations of sim¬ 
ply typed A calculus. To transform abstractions and applications of 
types and kinds, we extend the technique used by Morrisett et al 
[24] to transform System F type abstractions and applications. 

The result of applying the CPS transformation to the represen¬ 
tation of a term of type t is a term of type CPS r. The type CPS 
is shown in Figure 12. CPS is defined via a fold CPSi and a helper 
function Ct. The CPS-transformation itself is defined in Figure 13. 

Theorem 6.5 (Type of cps). 

() F cps : (Ila : U. Exp a -A CPS a) 

Coercions for CPS types are not identity functions, unlike those 
for UId and UBool types. As a simple example, note that for type 
variables a and /3, CPS (a[a := f3 -A 6]) is not equivalent to 
CPS (a[a 4>->- /?]). The former simplifies to CPS (Var (8 -A 



Ct = AT : IIV : (T -) V) -> V 

var = Aa : *. a 

prod,, = Aa : *. A/3 : *. Ct a —> Ct /3 

prod n = Ax : Aa : x -> *• H/3 : x- Ct (a /3) 

prod A = ATi :□->*. IIx Ct (Ti x) 

CPSi = Fold[var, prod*, prod n , prod A ] 

CPS = AT : U. Ct (CPSi T) 


Figure 12. The result type of CPS transformation 


w : Witness CPS 

abs, = Aa : U. A/3 : U. Af : CPS a -4 CPS /3. 

AV : *. Ak : (CPS a -4 CPS /3) —> V. k f 

app, = Aa : U. A/3 : U. Af : CPS (Prod, a /3). Ax : CPS a. 

AV : Ak : (CPSi /3) -4 V. 
f V (Ag : CPS a -4 CPS (3.gxVk) 

abs D = Ax : Aa : x U. Ae : {Ufi : X- CPS (a ,0)). 

AV : *. Ak : (CPSi (Prod n xa))->V. k e 

app D = Ax : Aa : (x ->• U). Ae : CPS (Prod n x a). A/3 : X- 
AV : *. Ak : (CPSi (a /3)) -4 V. 
e V (Aei : (n/3i : x- CPS (a /3i)).ei /3 V k) 

absA = Aa : □ -4 U. Ae : H X : □. CPS (a x)- 
AV : *. Ak : CPSi (Prod A a)^V.ke 

app A = Aa : □ -4 U. Ae : CPS (ProdA a). Ax : □ . 

e V (Aei : (n X i : CPS (a X i)).ei X V k) 

cps = fold[CPS, w, abs*, app*, abs n , app n , abs A , app A ] 


Figure 13. Specification of cps 


/3)), and the latter to CPS (Prod, (Var /3) (Var /3)). Coercions for 
CPS types add and remove continuations as necessary. 

We don’t attempt to formally verify the correctness of cps, 
though we validate it by testing it on the polyapp functions from 
Section 3.2. 

7. Experiments 

We conduct experiments using an implementation of System U, 
which is available from our website [1], We implement a parser 
in Ohm, a domain specific language for writing parsers and the 
successor to OMeta [34]. The parser generates abstract syntax for 
our Haskell implementation of System U, which includes type and 
term quoters, a validity checker, an evaluator, and an incomplete 
/3, jj-equivalence checker. We have used the implementation to me¬ 
chanically check that all System U terms, types and kinds presented 
in the paper are legal, and to verify the equivalence theorems. We 
have verified that self-applications of unquote, isAbs, and cps are 
legal and have normal forms. Furthermore, self-application of un¬ 
quote is equivalent to unquote itself, and self-application of isAbs 
evaluates to the Church boolean true: 

quote(unquote) = q 

unquote (ha : U. Exp a -4 UId a) q =g i?7 unquote 


S *,□ 

F* A * : □ 

n (*,*),(□,*),(□,□) 


Figure 14. PTS specification of F* 


quote(isAbs) = q 

isAbs (na : U. Exp a -4 UBool a) q =p, v true 

We have validated cps by applying it to each of our polyapp 
functions from Section 3.2. 


8. Related Work 

The problem of typed self-representation has been studied since 
1991, when Pfenning and Lee considered whether System F (A2) 
could represent itself [26], They found that “metacircularity seems 
to be impossible” for System F. However, they developed several 
typed representations of one language in another - System F in 
System F^ , and F„ in F+. Their representation technique inspired 
our own. They use higher order abstract syntax similar to ours, 
with two important differences. They don’t represent types, and 
their quoter does not change the types of variables. Each of these is 
important for our typed cps transformation. 

The key idea of decomposition of product types is already 
present in Pfenning and Lee [26]. The idea recurs throughout the 
literature on typed HOAS representations. In the setting of pure 
type systems, the pattern becomes more clear. We identify decom¬ 
position of product types and abstraction of the resulting compo¬ 
nents as key requirements for typed representation of a pure type 
system. 

Rendel, Ostermann, and Hofer [27] defined the first typed self¬ 
representation and self-recognizer (which they called eval). They 
study a language F* defined in Figure 14. Like F w , System F* 
contains the rule (□, □) which allows formation of higher-order 
types. Unlike F w , which classifies types using a family of kinds 
induced by the sort A and axiom □ : A, System F* adds an axiom 
□ : □, which forms types that classify other types. Types that 
classify other types play the role of “kind” in System F* . This is 
sufficient to tie the knot: abstractions formed by (□, *) can abstract 
over both types and “kinds” in terms. Similarly, (□, □) can abstract 
over both types and “kinds” in types. 

Our type representation is partly inspired by that of [27], which 
represents the types of simply typed A-calculus in F*. They use 
type representations in a representation of simply-typed A-calculus 
in F*, which supports a typed CPS transformation. Our self¬ 
representation of System U and CPS transformation are also in¬ 
spired by their representation and CPS transformation of simply- 
typed A-calculus. 

Like System U, System F* is not normalizing. Unlike System 
U, type checking of F£ is undecidable due to the |g^o) rule. We 
conjecture that System U can be embedded into F* , but that System 
F* cannot be embedded into System U. 

Our representation of types is also inspired by Saha et al. [30]. 
They study intensional type analysis for A" which, like System U, 
includes type and kind polymorphism. They encode base types of 
kind O (analogous to * in System U) using HOAS. The kinds of 
their HOAS type constructors parallel the kinds of the constructors 
of our type representations. 

Xf Kind System U Kind 

-4 Q -4 f2 -4 n Prod, U -4 U -4 u 

v Vx.(x-> ft) -4 n Prod D n X : D.(x -4 U) -4 u 

V+ (Vx-O) -4 n ProdA (□ -4 U) -4 U 





Despite notational differences, there is a direct correspondence 
between the kinds of the constructors for A“ types and our type 
representations. The binders V and II play the same role in each 
calculus. Furthermore, in System U □ —» U is shorthand for 
n X : n.U (since x does not occur free in U). A subtle difference 
is that there is no classifier for the kinds of A" (they use a well- 
formedness condition), while in our PTS formulation of System U 
all kinds are classified by □. Saha et al. include a type operator 
Typerec for intensional type analysis of base types based on folds. 
They support fold operations that produce higher-kinded results. 
The Typerec operator is primitive, which avoids the need for type 
representations. They did not study self-representation of System 
Xf, and it is an open question whether it would be possible. We 
conjecture that System U can be embedded into A", but A" cannot 
be embedded into System U. 

Typed representation has been extensively studied, and is still 
an active area of research. Chen and Xi [10, 11] studied typed rep¬ 
resentation and typed meta-programming. Carette, Kiselyov and 
Shan [9] use typed representation to build tagless interpretations. 
McBride [20] achieved a metacircular representation of depen- 
dently typed languages in Agda. Axelsson [3] developed a tech¬ 
nique for building generic, composable typed representations as a 
solution to the expression problem [33], Each of these is important 
related work, and we have learned from and been inspired by them, 
even though they did not study self-representation. 

9. Future Work 

Size. Our representations do not support operations that measure the 
size of a term. This is a limitation of our higher order abstract syn¬ 
tax representation. Abstractions in the representation, particularly 
type abstractions, can block access to the size of subterms. Assum¬ 
ing the size operation should produce results of some closed type 
Nat, we would need a way to convert a term of type Ila : k. Nat 
to Nat. The quantification a is redundant, since a does not occur 
free in Nat. In order to recover the Nat, we would have to apply the 
term of type Ila : k .Nat to a type of kind k. This is not always pos¬ 
sible, since not all System U kinds are inhabited. In [27] this was 
addressed by adding a type constant _L : Ila : □ .a, which could 
be used to apply these abstractions. 

Beyond kind * Our representation of types is limited to types of 
kind *. Full representation of types is desirable, as it may eliminate 
the need for coercions and the witnesses that enable coercions. 
Full representation may also enable more operations. It is an open 
question whether full type representation is possible in System U. 

Without type representation. At the other end of the type rep¬ 
resentation spectrum, we can consider representation of terms that 
don’t require representation of types. We represent types in order to 
support our typed CPS transformation. In particular, type represen¬ 
tations allow us to give cps the polymorphic type Ila : U.Exp a —>- 
CPS a. The input and output types Exp a and CPS a are both de¬ 
fined in terms of the quantified variable a. Our other operations, 
unquote and isAbs, do not require any representation of types. It 
is possible to define a simpler representation type Exp x of kind 
* —j *, and a quotation procedure that represents terms of type 
t with terms of types Exp, r. The representation type and quoter 
would be similar to those from Rendel, Ostermann, Hofer [27], In 
particular, we would no longer require coercions. 

Strong normalization. Of the two A-calculi System F* and 
System U known to support typed self-representations, neither is 
strongly normalizing. It is an open question whether a language 
with decidable type checking and strong normalization can support 
typed self-representation. 

Representing open terms. Our quoter changes the types of vari¬ 
ables, which is important for our cps transformation, but also lim¬ 
its our representations to closed terms. Pfenning and Lee did not 


change the type of variables, which enabled them to represent free 
variables (i.e. those bound outside the representation) in the same 
way as bound variables. It is possible to extend our representation 
type with a new constructor for representing free variables, with the 
type: 

IIR : U ->■ *.IIa : *.a PExp R (Var a) 

To represent a free variable of type r, the quoter would first apply 
this constructor, producing a term of type PExp R (Var r). Then it 
would synthesize a coercion to change the type to PExp R r. Note 
that Var r = a[a := r] and that r s a [a := r]. 

Dependent Types. We can extend System U with dependent 
types by adding to 7 Z the rule (%0) that forms types that ab¬ 
stract over terms. The resulting system still supports polymor¬ 
phic application, which indicates that it might also support self¬ 
representation. Compared to the polyapp functions for System U, 
the only change required is to polyapp*, since (*, *) products can 
now be dependent. For example, in a product type Fix : T\. T2 
formed by (*, *), the bound variable x can now occur free in T2. 
The polyapp* function for the extended system could be defined 

An : *. An : n -» *. (Fix : n.r 2 x) -4 Yly : t\. r 2 y 
Note that the kind n —¥ * is formed by (*, □). We still have the 
property that □ is the only element of A, which is key to tying the 
knot. However, the addition of dependent types would raise two 
challenges for type representation. The first is due to the introduc¬ 
tion of non-normalizing types (e.g. because types can contain non¬ 
normalizing terms). Our type representation in this paper only ap¬ 
plies to types in normal form. Second, the type representation must 
consider how to represent types that depend on terms. 

10. Conclusion 

The question of whether a meaningful notion of typed self-represen- 
tation is possible for a language with decidable type checking has 
been open since 1991 [26]. We answer in the affirmative by pre¬ 
senting the first typed self-representation for a A-calculus with 
decidable type checking. Our calculus is System U, which was in¬ 
troduced in Girard’s PhD thesis [16]. We embed representations of 
types into representations of terms, which enable operations like 
CPS transformation that change the type of a term. Our representa¬ 
tion supports operations that iterate over the term, and we provide 
three example self-applicable operations: a typed self-recognizer 
that recovers a term from its representation, a predicate that tests 
the intensional structure of a term, and a typed CPS transforma¬ 
tion. Ours is the first typed self-applicable CPS transformation. 
We have validated our results by conducting experiments using an 
implementation of System U in Haskell. 
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Figure 15. Kind of type representations 


PExp = AR : U -> * 

Witness R —> 

Abs, R -> App* R —> 
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AbsA R —> App A R —» 
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Figure 16. Type of pre-quotations 


A. Encoding 

A.l Type Representations 

In this section we provide concrete definitions of the kind U of type 
representations, the constructors of type representations, and the 
Fold[... ] context. Our representations of types use a Church-style 
encoding. Figure 15 shows the kind U of type representations. 

Theorem A.l. {) F U : □ 

Proof. Straightforward. □ 

The file lib/reptypes .pts defines the constructors for our 
type representations. 

Theorem A.2 (Kinds of Type Representation Constructors). 


Theorem A.4 states that an operation on type representations 
folds over the structure of its input. For example, a case function 
F 2 for (*, *) products of the form n —» T 2 maps the results of the 
operation on n and T 2 to a result for n —> T 2 . The other cases are 
similar. 

A.2 Term Representations 

In this section we provide concrete definitions of the type PExp 
of pre-quotations, the constructors of term representations, and the 
fold[... ] context. Our representations of types use a Church-style 
encoding. Figure 16 shows the type PExp of pre-quotations. 
Theorem A.5. () F PExp : (U ->• *) ->■ U -» * 

Proof. Straightforward. □ 


() '• Var : * -+ U 

() h Prod, : U —» U ->■ U 

() F Prod D : (n X : ( X ~1 U) —>• U) 

() F Prod A : (□ -A U) -> U 

Proof. Machine-checked. □ 

Definition A.l. Suppose var, prod*, prod n , and prod A satisfy: 

0 F var : * ^ * 

() F prod* : * —> * —> * 

0 I" Prod n : (n X :□.(*:->*)-» *) 
f I" prod A 

Then Fold[var, prod*, prod n , prod A ] denotes the type: 

Aq: : U. a var prod* prod n prod A 

Theorem A.3. Let F = Fold[var, prod*, prod D , prod A ]. Then 
(} F F : U -> * 

Proof. Straightforward. □ 

Theorem A.3 states that all folds on type representations have 
kind U —t *. The proof is straightforward, since Fold[... ] is only 
defined when the case functions have the expected kind. 

Theorem A.4. Suppose T F r : *, and let F = Fold[Fi,F 2 , F 3 , 
F 4 ]. Then: 

F t =p Fi t If r is of the form an ... t„ 

F t =/3 F 2 (F n) (F n ) If r = n ->• r 2 , T F n : * 

Frs,) F 3 k (Aa : k. F rf) If r = Ila : k.ti , TF / t : □ 

Fr = p F 4 (A X : □. FfT) If t - II X : □. n 

Proof. By straightforward case analysis. In each case, we expand 
the definitions of r, F, Fold[... ], and the constructors Var, Prod*, 
Prod n , and ProdA on both sides of the equivalence. Then a few 
simple /3-reductions establish the equivalence. In the fifth case 
(when e is a type application of the form ei T 2 , we also rely on 
Femma A. 11. □ 


The file lib/replib. pts defines the constructors for our term 
representations. 


Theorem A .6 (Types of Term Representation Constructors). 


{} F mkVar 
(} F ink Abs. 

{) F mkApp* 

{) F mkAbsn 

() F mkApp . 


: (IIR : U —k *. Ila : U. R a -> PExp R a) 

: (IIR : U —> *. Ila : U. II/? : U. 

(R a ->■ PExp R /3) —> PExp R (Prod, a /?)) 

: (IIR : U —k *. Ila : U. : U. 

PExp R (Prod, a 8) PExp Ra-I PExp R (?) 

: (IIR : U —k *. n« : □. IIa : (k ^ U). 

(II/? : k. PExp R (a /?)) -> PExp R (Prod D k a)) 

: (IIR : U —> *. IIk : □. Ila : (k -> U). 

PExp R (Prodo k a) — Y II/3 : k. PExp R (a /3)) 


§ F mkAbsA : (nR : U ^ *. Ila : □ -> U. 

(n X : PExp R (a X )) -> PExp R (Prod A a)) 


() F mkApp A : (IIR : U —^ *. Ila : □ —> U. 

PExp R (ProdA a) —> II X : □. PExp R (a X )) 


Proof. Machine-checked. 


□ 


Definition A.2. Suppose F, w, abs,, app*, abs D , app n , abs a, and 
app A satisfy: 

(>FF : U —k * 

() F w : Witness F 

() F abs* : Abs, F (} F app* : App* F 

() F ahs D : Abs c F () F app n : App n F 

0 F absA : AbsA F () F app A : App A F 

Then fold[F,w,abs*,app*,ahs n ,app n ,absA,app A ] denotes the 

Aa : U. Ae : PExp F a. e w abs, app* abs Q app n absA app A 
Theorem A.7. Suppose F, w, abs,, app*, abs a , app n , absA, and 
app A are as in Definition A.2. If f = fold[F, w, abs*, app*, abs n , 
app n , absA, appA], then F1 f : (Ila : U. PExp F a —> F a). 



Proof. Straightforward. □ 

Pre-quotations are functions of seven arguments - a witness, 
and six fold functions. To reason about the behavior of a pre¬ 
quotation, we must consider applications of it to seven arguments. 
As a convenience, we define a one-hole context ip{-) to form such 
applications. 

Definition A.3. For any terms e, w, fi, ..., f6 (where w, fy, ..., f6 
are to be inferred by context), denotes the term ewfi ... fg. 

Lemma A.l (Semantics of representation constructors). For any 
w, fi, ..., f6.' 

1) ^(mkVar Rrx) =p x 

2) r/>(mkAbs* R n T2 q) fi n r 2 (Ax : R n. 4>{q x)) 

3) r/>(mkApp* R n r 2 q x q 2 ) =p f2 n r 2 V’(qi) ip(q 2 ) 

4) i/>(mkAbs n R k t q) =p f 3 k t (Aa : k. ip{q}) 

5) ^(mkApPa R k t q n) =p f 4 kt q) n 

6) r/)(mkAbsA R r q) =p f 5 r (Ax : tp(q)) 

7) V)(mkApp A Rrq/t) =p f 6 r V>(q) k 

Proo/ Straightforward /3-reduction. See the definitions in 
lib/replib.pts. □ 

While folds are only defined on prequotations, which have types 
of the form PExp F, we can apply a fold to a quotations by applying 
the quotation to the result type F. 

Theorem A.8. Suppose F, w, abs*, app*, abs D , app n , absA, and 
app A are as in Definition A.l. Iff =fold[F, w, abs *, app,, abs a , 
app n , abs a, appA ], then: 

{) b (Aa : U. Ax : Exp a. f a (x F)) : (Ila : U. Exp a —» F a) 

Proof. We have that Exp a =p (IIR : U —> *. PExp R a), 
so a : U, x : Exp a b x F : PExp F a. By Theorem A.7 
a : U, x : Exp a b / : (Ila : U. PExp Fa-> Fa). Therefore, 
a : U. x : Exp a b f a (x F) : F a. Therefore, we can derive the 
result by two uses of the abstraction rule. □ 

A.3 Coercions 

The need for coercions arises from the fact that not every type of 
kind U is a type representation. Consider a type t = a —¥ /.3 of kind 
*. We can construct multiple types of kind U from the components 
of t: 

Var (a -t /3) 

Prod* (Var a) (Var 0) 

It happens that the second type is r, the representation of r. We 
might call the first a pseudo-representation of r: it is a type of kind 
U, the kind of type representations, but is not the representation of 

A similar situation arises with term representations. Suppose a 
term e has type Ila : k.t, and a type n has kind k. Then e n 
has type r[a := n]. Now, suppose e has type PExp R r. Then 
mkApp n k (Aa : k.t) e n has the type PExp R (r [a := n]). This 
is in general not equivalent to PExp R (r[a := Ti]), so we insert a 
coercion to convert a term of type PExp R (r[a := n]) to one 
of type PExp R (r[a := n]). These coercions are automatically 
constructed by the quoter. To enable this, we require operations 
with a result type function R to satisfy the property: 

Property A.l (Coercibility of operations). For all types r and n, 
there exists a coercion c of type: R (r[a := n]) —> R (rja 55 rtj). 


The property is witnessed by a tuple of functions that the quoter 
uses to construct coercions. There are three coercion functions for 
each of the rules (*, *), (",*). and (A, *). They are: 
dist s Adds one level of type representation. 
factor s Removes one level of type representation, 
coerce® Applies coercion(s) to the components of a 
representation. 

When we say that dist s adds a level of type representation, 
we mean that it encodes only the top-level form of a type. For 
example, dist* maps terms with types of the form R (Var (a —*■ fi)) 
to R (Prod* (Var a) (Var 0)). The name dist* reflects that we 
distribute Var over the arrow. 

The factors witness functions go the opposite direction as the 
dists ones. For example, factor* maps terms with types of the form 
R (Prod* (Var a) (Var 0)) to R (Var (a -# 0)). 

The coerce® witness functions is a constructor for coercions on 
(s, *) products. 

We use the witness functions to define nine coercion functions 
with types listed in Figure 18. Coercions of type Reify* R map 
R (Var (n —» t 2 )) terms to R n — ¥ t 2 terms. They take as input 
a reflect coercion for t\ and a reify coercion for r 2 . Coercions of 
type Reflect* R map R Ti r 2 terms to R (Var (n —>- r 2 )) terms. 
They take as input a reify coercion for n and a reflect coercion 
for t 2 . Coercions of type Coerce* R map R (Prod* n r 2 ) terms to 
R (Prod* o 1 of) terms, taking as input coercions from R o 1 to R n 
and from R r 2 to R 02. 

Each operation is required to supply a witness of property A.l, 
which is a tuple of nine functions. The types of these functions are 
listed in Figure 17. 

A.4 Coercion Constructors 

We use witnesses to define coercion constructors, whose types 
are listed in Figure 18. The quoter uses the constructors to build 
coercions with types of the form 

PExp R (r[a := n]) -> PExp 

The file lib/coercelib.pts defines the functions reify,, 
reflect®, and coerce® for each s £ {*, □, A}. 

Lemma A.2. The functions reify ,, reflects, and coerce s for each 
s £ {*, □, A} have the types listed in Figure 18. 

Proof. Machine checked. □ 

Figure 19 defines the coercion construction process used by the 
quoter. The notation n r 2 denotes the coercion from PExp R n 
terms to PExp R r 2 terms. They are constructed inductively by the 
structure of n and r 2 . 

Lemma A.3 (Reification and Reflection). If t is a normal form 
and T b r : *, then there exist terms ci and c 2 such that: 

Proof. Straightforward, by induction on the height of the derivation 
of r b r : □ 

Theorem A.9 (Completeness of Coercion Construction). IfY, a : 
k b t : * and T b n : *, then there exists terms c 1 and c 2 such 
that: 

r[a :=3gb ^ r[ot := n] = ci 
r[a :=:a$|^-F[a := n] = c 2 

Proof. Straightforward by induction on the height of T, a : K b r : 

*. □ 





Dist* : (U —4 *) —4 * = 

AR : U -4 *. na:U. n/3:U. 

R (Var (UId a -4 UId 8)) :-4 
R (Prod, (Var (UId a)) (Var (UId /?))) 

Factor* : (U -4 *) -4 * = 

AR : U -4 *. n«:U. n/3:U. 

R (Prod, (Var (UId a)) (Var (UId 8))) -4 
R (Var (UId a -4 UId 8)) 

Coerce, : (U -4 *) -4 * = 

AR : U -4 *. na:U. n/3:U. liar :U. II81 :U. 

(R ni->Ra)-MRHRft)-> 

R (Prod, a /8) —► R (Prod, ai 81) 

Dist n : (U -4 *) -4 * = 

AR : U -4 *. n x :D. IIa:x -4 U. 

R (Var (n/3:*. UId (a 8))) -4 
R (Prod D x (A/8:x• Var (UId (a 8)))) 

Factory : (U -4 *) -4 * = 

AR : U -4 *. n x :D. IIa:x -4 U. 

R (Prod D X (A/8:X. Var (UId (a 8)))) -4 
R (Var (n8: X . UId (a 8))) 

Coerce D : (U -4 *) -4 * = 

AR : U -4 *. n x :D. Ilai: X —4 U. IIa2: X -t U. 
(U8:X• R (al 8) -4 R (as 8)) —4 
R (Prod n x on) —4 R (Prod D X as) 

DistA : (U —4 *) —4 * = 

AR : U -4 *. Ila : □ -4 U. 

R (Var (II x :n. UId (a X ))) —4 
R (ProdA (A X :a. Var (UId (a X )))) 

Factor a : (U -4 *) -4 * = 

AR : U —4 *. IIa:n —4 U. 

R (Prod A (A X : □. Var (UId (a X )))) -4 
R (Var (n x :n. UId (a X ))) 

Coerce A : (U -4 *) -4 * = 

AR : U -4 *. nai: □ -4 U. na 2 : □ -4 U. 

(n x : □. R (ai X ) —4 R (as x)) -4 
R (Prod A ai) -4 R (Prod A as) 

Witness : (U -4 *) -4 * = 

AR : U -4 *. na : *. 

(Dist, R —4 Distc R -4 Dist A R -4 
Factor, R -4 Factor^ R -4 Factor A R -4 
Coerce, R —4 Coerce D R —4 CoerceA R —4 



Figure 17. Types of Witness Functions 


Reify t : AR : U -4 *. na : U. 11/3 : U. 

(R a —4 R (Var (UId a))) -4 
(R (Var (UId /?)) -4 R 8) -4 
R (Var (UId a -4 UId 8)) -4 R (Prod,a 8) 
Reflect, : AR : U —4 *. Ila : U. 118 : U. 

(R (Var (UId a)) -4 R a) —4 
(R 8-4 R (Var (UId 8))) -4 
R (Prod,ct 8) -4 R (Var (UId a —4 UId 8)) 

Reify n : AR : U -4 *. II X : □. IPr : X -4 U. 

(na : X- R (Var (UId (r a))) 4 R (r a)) -4 
R (Var (na : x- UId (r a))) -4 R (Prod D k r) 
Reflect n : AR : U —4 *. II X : □. nr : X —4 U. 

(na : X- R (r a) 4 R (Var (UId (r a)))) -4 
R (Prod n kt) 4R (Var (na : x- UId (r a))) 

Reify A : AR : U —4 *. nr : □ —4 U. 

(nx : R (Var (UId (r X ))) 4R(r x)) -*■ 
R (Var (n X : □. UId (r x))) -4 R (Prod A t) 
ReflectA : AR : U —4 *. nr : □ —4 U. 

(nx : R (r x) -4 R (Var (UId (r X )))) -4 
R (ProdA t) -4 R (Var (n X : UId (r x))) 

reify„ : Reify, (PExp R) 
reflect* : Reflect* (PExp R) 
coerce* : Coerce, (PExp R) 
reify D : Reify n (PExp R) 
reflect^ : Reflect^ (PExp R) 
coerce 0 : Coerce 0 (PExp R) 
reify A : Reify A (PExp R) 
reflectA : ReflectA (PExp R) 
coerceA : CoerceA (PExp R) 


Figure 18. Types of Coercion Functions 


Theorem A.10 (Types of Coercions), //r I- n : U and r F ts : 
U, and T% 4v4 Ts '= c, then 

f? : U —4 *, r F c : PExp R n -4 PExp R Ts 

Proof. Straightforward by induction on the height of n fg. = c, 
and by Lemma A.2 and Theorem 4.2. □ 

Now we turn to the semantics of coercions. Coercions are built 
from witnesses, which Church tuples of 9 components. We begin 
by defining a set of witness projection functions. 

Definition A.4 (Witness Projection Functions). Let R be a type 
of kind U —4 *, which is to be inferred from context. For i € 
(1,..., 9 },Wi denotes the witness projection function: 

Axi : Dist, R. Ax2 : Factor, R. AX3 : Coerce* R. 

AX4 : Dist n R. Axs : Factor^ R. Ax6 : Coerce c R. 

Ax 7 : DistA R. Ax g : FactorA R. Ax 9 : CoerceA R- X; 

Lemma A.4 (Witness Projections are Normal Forms). For i € 
{1,..., 9}, Wi is a normal form. 

Proof. Trivial. □ 

Now we turn to the semantics of coercions. Coercions rely on a 
function lift that maps terms of type R a to terms of type PExp R a. 
The definition of lift is in lib/replib. pts. 

Lemma A.5 (Type of lift). {} h lift : (FIR : U -4 * 

U. R a -4 PExp R a) 


4. Ila : 





(Var r Var r) = \x : PExp R (Var r).x 


Var n) = reflect T1 (Var ti T2) = reify T2 


(Var (n 

t 2 )' 

^ Tl ~ 

: F72) 

= reify* 

R ri T2 reflect T1 reify T2 

(Var n - 


)~ reify,. 

(72- 

^ Var t 2 ) = reflect-., 

(Tl -» T2 ~ 

- Var 

(ri -»• 

r 2 )) 

= reflect. 

k R rT 72 reify Tl reflect^ 


(cri 

■** n) 

= Cl 

(r 2 

o- 2 ) = c 2 

(Prod* n 

T2 Prod* 

cr 1 o 2 ) = coerce* R n T2 cri 1X2 Ci C 2 




(Var- 

r) -sc* r - 

= c 

Var (Ila : k 

.r) ^ na : 


= reify □ 1 

R k (Aa : k.t) (Aa : k. c) 




T ~ 

(Var r) = 

= c 


Ila : k.t Var (Ila : k.t) = reflect^ R k (A a : k.t) (Act : k. c) 


(Prod n k (Aa : k. t)) (Prod n k (Aa : n. <7)) 

= coerce D R k (Aa : k.t) (A a : k.o ) (Aa : k. c) 

(Var t) r = c 

Var (n X : D.r) — Fix : O.t = reify A R (Ax : D.r) (Ax : c) 
t M (Var r) — e 

1 % : D.r Var (IIx : D.r) = reflectA R (Ax : D-t) (Ax : □. c) 


(Prod A (A X : r)) — (Prod A (A X : <?)) 

= coerce A R (Ax : U.t) (Ax : D-ff) (Ax : c) 


Figure 19. Coercion Construction 


Proof. Machine-checked. □ 


Lemma A.6 (Semantics of lift). For all R, a, e, U(lift R a e) =a e 


Proof. Straightforward /3-reduction. See the definition of lift in 
lib/replib.pts. □ 


Lemma A.7 (Semantics of primitive coercion constructors). For 
any w, fi, ..f6.- 

1) i//(dist* R n T2 e) 

=0 w (Dist* R) wi ti t 2 tp{e) 

2) ///(factor* R n T2 e) 

=0 w (Factor* R) W2 n T2 t//(e) 

3) ip{c oerce* R n T2 <ti 02 Ci C 2 e) 

=0 w (Coerce* R) W3 n T2 <ri 02 

(Ax : R cri. ip (ci (lift R ai x)}) 

(Ax : R T2. ip(c2 (lift R T 2 x))) 
ip{e) 


4) t/»(dist n R k t e) 

w (Dist n R) W4 k r ip{e>) 

5) i//(factor D R/tre) 

5,8 w (Factor n R) W5 n t ip(e) 

6) ^coercen Rcrirce) 

=0 w (Coerce D R) we /t to 

(Aa : k. Ax : R (r a). tf(c a (lift R (r a) x)» 
i>{e) 

7) ///(dist a R r e) 

w (Dist a R)w 7 kt ip(e) 

8) ///(factor a Rre) 

=0 w (Factor a R) ws r z//(e) 

9) ///(coerce a R t 0 c e) 

=0 w (CoerceA R)wgrcr 

(Ax : Ax : R (r X ). V>(c X (lift R (r x) *)» 
i>{e) 


Proof. Straightforward /5-reduction. See the definitions in 
lib/coercelib.pts. □ 


Lemma A.8 (Semantics of derived coercion constructors). For any 
w. fi.f 8 : 

1) ■(/'(reify,, R n 7-2 Ci C2 e) 

~0 ip( coerce* R (Var (UId n)) (Var (UId r 2 )) n r 2 
Ci C2 (dist* R 7*1 T2 e)) 

2) ip (reflect* R n 72 Ci C2 e) 

•^0 ip (factor* Rn T2 

(coerce* R n T2 (Var (UId n)) (Var (UId T2 )) Ci C 2 e)) 

3) //; (reify D R k t c e) 

tjfcg z//(coerce n R k (Aa : k. Var (UId (r a))) r c 
(dist D R/tre)) 

4) ///(reflect a R/trce) 

///(factor D Rkt 

(coerce n Rkt (Aa : k. Var (UId (r a))) c e)) 

5) t/i (reify A R r c e) 

~0 1//(coerceA R (Ax : Var (UId (r x))) t c 
( distA Rre)) 

6) ip (reflectA Rre e) 

Sgg t/i(factorA Rr 

(coerceA R r (Ax : Var (UId (r x))) c e)) 


Proof Straightforward /5-reduction. See the definitions in 
lib/coercelib.pts. □ 


Lemmas A.9, A. 10, and A. 11 show that operating on a coerced 
pre-quotation is equivalent to operating on the prequotation, then 
coercing the result. 




Lemma A.9. 


1) 

ip( dist, R Ti r 2 e) 

=0Ctp(e), for some c 

2) 

?/> (factor, R n r 2 e) 

=0 cip(e), for some c 

3) 

^(coerce, R n r 2 m a 2 Ci c 2 e) 

=0Cip(e), for some c 

4) 

V)(dist n Rkt e) 

=0 c i>(e), for some c 

5) 

V>(factor n Rcre) 

=0Cip(e), for some c 

6) 

V>(coerce n Rcrircie) 

=0eip(e), for some c 

7) 

(dist a Rcre) 

=0C i>(e), for some c 

8) 

1/)(factorA Rcre) 

=0ci>(e), for some c 

9) 

ip( coerceA R k t a Ci e) 

=0 c if){e), for some c 

Proof. Straightforward by Lemma A.7. 

[ 

Lemma A. 10. 



1) (reify, R n r 2 Ci c 2 e) = t 

icip(e), for some c 


2) ^(reflect* R n r 2 Ci c 2 e) =[ 

jc ; 0(e), for some c 


3) i/9(reify 0 R k t Ci e) =/ 

jc ; 0(e), for some c 


4) i/)(reflectn R k t Ci e) = t 

jc ip(e), for some c 


5) ip( reify A R r ci e) = t 

jc ip(e), for some c 


6) i/)(reflectA Rrcie) E/ 

)C ; 0(e), for some c 


Proof. Straightforward by Lemma A.8 and Lemma A.9. Each case 
is similar, and (1) is representative. 

Case (1): By Lemma A.8 and then Lemma A.9 (1) and (3), we 
have that: 

^(reify* R n r 2 Ci c 2 e) 

=0 ip( coerce* R (Var (UId n)) (Var (UId r 2 )) n r 2 
ci c 2 (dist, R ti r 2 e)} 

*f# c ' ( c " '•'{ c » 

The result holds with c = Ax : R (Var (UId n —¥ UId r 2 )). c' (c" x). 

□ 

Lemma A.ll. If ti r 2 = c, then there exists a c such that 
cj>(c e) =£ c' </>(e) for all e. 

Proo/ Straightforward, by Lemmas A.9 and A. 10. □ 

The following theorem states that our encoding meets the spec¬ 
ification of Definition 5.3. 

Theorem A.ll. Suppose F, w, abs*, app*, abs n , app n , absA, and 
app A are as in Definition A.2, and suppose f = fold[F, w, abs*, 
app», abs D , app D , absA, appA]. Then for any context T, term e, 
and type r such that T h e : r, we have that: 

If e is a variable, then f r e Mb e. 

If r = n —> r 2 , T b n : *, and e = Ax : n. ei, then 
f t e =0 abs, ri r 2 (Ax : FrT- f rj eT). 

If e = ei e 2 , T h e 2 : n : *, then 

f t e =0 app* nr (fn->T el) (f n e^). 

If r = Ila : k.ti, T h k : □, and e = Xa : k. ei, then 
f t e =0 ahs D k (Xa : k. n) (A a : k. frTeT). 

If e = ei r 2 , T h tt : and F ei : Ila : k. n, then 
f r e =0 c (app n k (Xa : k. rf) (flip:: k. n ei) t 2 ) 
for some coercion c 

If t = U X : □. Ti, and e == Ax : ei, then 
f t e =0 ahsA (Ax : □■n) (Ax : f n el). 

If e = ei k, T h k : □, and T h ei : IIx : □. n, then 
fre=0 app A (Ax : n) (?!% : □ .n el) k. 


Proof. By straightforward case analysis. For each case, we expand 
the definitions of r, e, f, fold[... ] on both sides of the equivalence, 
and apply Lemma A.l. For the fifth case (type application), we use 
Lemma A. 11 □ 


B. Normalization of Representations 

We now prove strong normalization for our representations. For 
convenience, we define a new one-hole context #(•), which is 
similar to i/>(-) except that we require that w, fi,..., f6 be variables. 
Definition B.l. For any term e, 9(e) denotes the term e w fi ... f6, 
where w,fi, ... ,fe are variables. 

Definition B.2. Suppose that 9(e) is strongly normalizing (SN). 
Then we say that e is 9-SN. 

Definition B.3. Suppose that c is a term such that whenever e is 
9-SN, c e is 9-SN. Then we say that c is 92-SN. 

Lemma B.l. If e is 9-SN, then e is SN. 

Proof. Suppose e is 0-SN. By definition, 9(e) =p e w fi ... fe is 
SN. Therefore, e is SN. □ 

Lemma B.2. For any R, r, e, ife is SN, then lift R r e is 9-SN. 

Proof. Suppose e is SN. We must show that 0(lift R t e) is SN. We 
have that 9(-) is a particular case of a U(-), so by Lemma A.6 we 
have that 0(lift Rre) =g e. By assumption, e is SN, so 0(lift Rre) 
is SN as required. □ 

Lemma B.3. 

1. VR, n, r 2 : dist, R n r 2 is 92-SN. 

2. VR, n, r 2 : factor, R n r 2 is 92-SN. 

3. VR, n, t 2 , i7i, <7 2 , Ci, c 2 : If Ci and c 2 are 92-SN, 
then coerce, R n r 2 ai <r 2 ci c 2 is 92-SN. 

4. VR, k, t: dist a R Kris 92-SN. 

5. VR, K, t: factory R kt is 92-SN. 

6 . VR, k, r, a, c: Ife a is 92-SN for all a, 
then coerce n Rkt a cis 92-SN. 

7. VR, t: distA Rkt is 92-SN. 

8 . VR, r: factor A Rkt is 92-SN. 

9. VR, r, o, c: Ife x is 92-SN for all X , 
then coerce a Rt o cis 92-SN. 

Proof. Each case is similar. (9) is representative. 

Suppose c x is 02-SN for all X , and suppose e is 9-SN. We must 
show that (coerce a R r a c e) is SN. By Lemma A.7, we have 
that: 

0(coerceA Rrace) 

=0 w (CoerceA R) W9 r <7 

(Ax : □. Ax : R (r x)- 9( c x (lift R (t X ) x))) 9(e) 

Note that w is a variable. By Lemma A.4, we have that W9 is a 
normal form. Since (CoerceA R), t, and a are types, they are all 
SN. Since x is a variable, it is SN, so (lift R (r x) x) is 9- SN by 
Lemma B.2. Since c X is (92-SN, 9( c X (lift R (r x) x )) is SN. 
Therefore the term (Ax : ...) is SN. Since e is i9-SN, 9(e) is 

SN. Therefore the entire term is SN. □ 

Lemma B.4. 

1. VR, Ti, r 2 , Ci, c 2 , if Ci and c 2 are 92-SN, then 
reify* R n r 2 ci c 2 is 92-SN. 

2. VR, n, r 2 , ci, c 2 , if Ci and c 2 are 92-SN, then 
reflect* R ri r 2 Ci c 2 is 92-SN. 

3. VR, k, r, c, if c a is 92-SN for all a, then 
reify n Rre is 92-SN. 

4. VR, k, t, c, ife a is 92-SN for all a, then 
reflect Rre is 92-SN. 

5. VR, r, c, ife X is 92-SN for all X , then 
reify A Rre is 92-SN. 













6. VR, r, c, if c x is 02-SNfor all x, then 
reflectA R r c is 02-SN. 

Proof. Each case is similar. (3) is representative. 

Let c be such that c a is 02-SN for all a, and let e be 0-SN. We 
must show that 0(reify D R k c e) is SN. By Lemma A.8, we have 
that 

0 (reify D R k t c e) 

=p 0(coerce n R k (Aa : k. Var (UId (r a))) r c 
(dista Rkt e)} 

By Lemma B.3, coerce n R k (Aa : n. Var (UId (r a))) r c 
is 02-SN. Also by Lemma B.3, disto R k t is 02-SN. Therefore, 
(dista R k t te) is 0-SN, which in turn gives that the entire term 
0 (coerce a ...} is SN. Therefore, reify n R k r c is 02-SN. □ 

Lemma B.5. If t% ra = c, then c is 02-SN. 

Proof. Straightforward by induction on the height of the derivation 
of T\ T2 = c, and by Lemmas B.4 and B.3. □ 

Lemma B.6. 

1. VR, r, x : Ifx is a variable, then mkVar Rrxis 0-SN. 

2. VR, Ti,7~2,q : If qx is 0-SN for any variable x, then 
mkAbs* R ri T2 q is 0-SN. 

3. VR, ri, T2, q,, q 2 : If q 2 and q 2 are 0-SN, then 
mkApp t R n 7*2 q, q 2 is 0-SN. 

4. VR, k, t, q : Ifq a is 0-SN for any variable a, then 
mkAbsa R k t q is 0-SN. 

5. VR, k, t, q, t i : If q is 0-SN, then mkApp n R k t q n is 0-SN. 

6. VR, r, q : Ifq x is 0-SN for any variable x, then mkAbsA R t q 
is 0-SN. 

7. VR, r, q, « : 7/q is 0-SN, then mkApp A R k t q k is 0-SN. 

Proof. Each case is similar. (3) is representative. 

Suppose q, and q 2 are 0-SN. By Lemma A.l, 0(mkApp t R 
n T2 qj q 2 ) =p f2 ri T2 0(q x ) 0(q 2 ). Since f2 is a variable, n and 
T2 are types, and 0{q,} and 0(q 2 ) are SN, the entire term is SN as 
required. □ 

Lemma B.7. IfT b e : r ► q, then q is 0-SN. 

Proof. Straightforward by induction on the height of the derivation 
JPf- e : r ► q, and by Lemma B.6 and Lemma B.5. □ 

Lemma B.8. IfT b e : r ► q, then q is SN. 

Proof. Follows from Lemma B .7 and Lemma B. 1. □ 

C. Proofs 

Definition C.l. A PTS is called functional (or singly-sorted) if 

1. (c : Si), (c : s 2 ) € A => Sr = s 2 

2. (si, S2, S3), (si, S2, s' 3 ) € H “4- «3 = S3 

Theorem C.l (Uniqueness of types in a functional PTS [5]). Let 
A S be a singly-sorted PTS. Then 

rbA:Bi&rbA:B 2 =4 B|j|| B 2 
Definition C.2. A PTS is called injective if 

1. It is functional 

2. (si : S2), (si : S2) E ^4 si = 

3. (si, s 2 , s 3 ), (si, S2, s 3 ) G 1L *4 s 2 — s 2 

Theorem C.2. Typechecking of an injective PTS is decidable [6], 


Lemma C.l. System U is functional. 

Proof. 

1. Each constant c is in the left-hand position of at most one 

2. Suppose (si, s 2 , S3), (si, S2, S3) £ 1Z. Then S2 = S3 and 
s 2 — S3. Therefore, s 3 = s 3. 

□ 

Lemma C.2. System U is injective. 

Proof. 

1. By Lemma C.L 

2. Each sort s is in the right-hand position of at most one axiom. 

3. Suppose (si, S2, S3), (si, s 2 , S3) 6 1Z. Then s 2 = S3 and 
s' 2 = S3. Therefore, s 2 — s 2 . 

Theorem C.3. Type checking is decidable for AU. 

Proof. Follows from Lemma C.2 and Theorem C.2. □ 

Lemma C.3. If!' h r : k : □, then t has a normal form. 

Proof. The proof is by an embedding the types of System AU into 
the terms of System F, and the kinds of System AU into the types 
of System F. □ 

Theorem 3.2. IfT \~ t : *, and t is a normal form, then t is of 
one of the following forms: 

a A 1 ... A n where a is a type variable, 

n —» T2 where T • - n : * 

Ila : k. 7*i where T h k : □ 

LTx : n 

Proof. Straightfoward by Lemma C.3 and then by induction on the 
height of T h t : *. □ 

Theorem 3.3 (Decomposition of product types). For any legal 
(*, *) product t% —» T 2 , any legal (□, *) product Ha : k. t, and 
any legal (A, *) product Hx : □. t, we have: 

Tl t 7*2 =p 7T» Tl 7*2 

II a: k.t =p 7r n k (Aa : k. t) 
n x : t -.3 7TA (Ax : r) 

Proof. Straightforward by the definitions of 7r„, 7r n , and 7 ta. 

7T* Tl 7*2 

= (Aa : *. A/3 : *. a -¥ /3) n r 2 

■3 Tl —t T2 

7r n k ( Aa : k. t) 

= (Ax : Aa : x 4 *.II/3 : x-a P) k (Aa : k. t) 

=P (Aa : * -»• *.Hp : k. a p) (Aa : n. r) 
mp up : k. (Aa :k.t)P 

= a Ila : k. (Aa : k.t) a 
=p Ila : k. r 

7Ta (Ax : r) 

= (Aa : □ —» *.IIx : a x) (Ax : 7") 

=p IIx : (Ax : □. 7") x 

=p n X-U.T 

□ 






Theorem 4.1 (Kinds of type representations). If T b r : * and 
m t : * t> a, then fiber : U. 

Proof. Straightforward by induction on the height of the derivation 
r b r : * > a, and by the types of the constructors in Definition 
4.2. □ 

Theorem 4.2. If T b r : *, then UId r =g r. 

Proof. By induction the size of the type r. 

Suppose r is of the form a n ... r n . By Theorem A.4, 
UldT =/3 (\a : a) t = 0 r. 

Suppose t is of the form n —» T2 and T h n : By 

the induction hypothesis, UId TT =/3 Ti and UId 72 =ft T2. 
By Theorem 3.3, 7r» n T2 r. Therefore, by Theorem A.4, 
UId t =p TT, (UId n) (UId 75) =p tt* n r 2 r. 

Suppose r is of the form IIa : k. ti and I' b k : By the 

induction hypothesis, UId t[ =@ n. By Theorem 3.3,7r n k n 
r. Therefore, by Theorem A.4, UId t =# 7r n k (UId ti) fep 

Suppose r is of the form Fix : □. n and T h n : □. By the 
induction hypothesis, UId tT =,3 n. By Theorem 3.3, 7 Ta Ti =,9 r. 
Therefore, by Theorem A.4, UId fgj 7 Ta (UId rf) Sjg 7 Ta ti p§i- 
r. □ 

Lemma C.4 (Semantics of U Constructors). Let F = Fold[Fi, F2, 
F 3 , F 4 ]. Then, 

F (Prod* n t 2 ) =d F 2 (F ti)(F r 2 ) 

F (Prod D k t) =p F 3 k (A/3 : k. F (t /?)) 
F(ProdAT) =p F 4 (Ax : F(r x)) 

Proof. By the definition of Fold, we have that 
F = Aa : U. a Fi F 2 F 3 F 4 

F (Prod* n 7-2) 

=p (Prod* n ti) Fi F 2 F 3 F 4 

=P F 2 (n Fi F 2 F 3 F 4 ) (r 2 Fi F 2 F 3 F 4 ) 

=p F 2 (F Ti) (F7-2) 

F (Prod D k t) 

=p (Prodo k t) Fi F 2 F 3 F 4 
=P F 3 k (A/3 :K.raF 1 F 2 F 3 F 4 ) 

=p F 3 k (A p : k. F (r fi) 

F (Prod A t) 

=p (Prod A t) Fi F 2 F 3 F 4 
=P F 4 (A X : t x Fr F 2 F 3 F 4 ) 

=P F 4 (A X : F (t x)) 

□ 

Lemma C.5 (Kind of type representations in representation envi¬ 
ronment). IfT hr:*, then T h r : U. 

Proof. Sketch: By theorem 4.1, we have that T b ft : U. Since 
T and r are equivalent with respect to type and kind bindings, 

r h T : u. □ 

Lemma C.6. If t is a normal form and r, x : n F r : * and 
ft « = □. then f^:= k] := • 

Proof. Straightforward by Lemma 3.2, and by induction on the 
height of T, x : : *• □ 

—> *,T h q : PExpRr. 


Witness [R,d* , f* ,c* ,d n , f n ,c n ,dA , f a ,ca] = 

Aa : *. 

A f : 

(Dist* R —t Dist a R —> DistA R 
Factor, R —> Factor^ R —> FactorA R — > 

Coerce* R — t Coerce n R —¥ CoerceA R —¥ 

f d* f* c* d n f n c n dA fA ca 


Figure 20. Witness Context 


Proof. Straightforward by induction on the height of the derivation 
of r h e : t ► q, and Lemmas C.5 and C.6 and Theorems A.9 and 
A.10. □ 

Theorem 5.2 (Types of quotations). If () M e : r : *, and 
quote(e) = q, then () bq: Exp r. 

Proof. By definition of quote(-), we have that and q = AR : U — > 
*.qi and () h e : r ► qi. By Lemma C.7, R : U —»• f- 

(/, : PExp R t. Therefore, Q h q : (nR : U -» *. PExp R r). 
But () = (), and (IIR : U —t *. PExp R r) Jljl Exp r, so 
() h q : Exp r as required. □ 

Theorem 5.3. If quote(e) = q, then q is strongly normalizing. 

Proof. Suppose quote(e);q. Then q = AR : U —^ q, and 
() h e : t ► q x , for some r and q,. By Lemma B.8, q, is strongly 
normalizing. Therefore, q is strongly normalizing. 

□ 


Definition C.3 (Witness Context). For R,d*,f r ,c t , d a ,f a , c D , dA, 
/a,ca such that: 

• () h R : U —► * 

• () h d* : Dist* 

• () h f, : Factor* 

• () F c, : Coerce, 

• () b d D : Distn 

• () h f n : Factor n 

• () b c n : Coerce n 

• () b- dA : DistA 

• () h- fA : FactorA 

• () h- Ca : CoerceA 

We define the term Witness[R,d,,f*,c ,, d D , /□, c D , dA, /a,ca 7 
as in Figure 20. 

Theorem C.4 (Type of witnesses). Let R, d t , f*,c*, d D ,fa, c a , dA, 
/a,ca be as in Definition C.3. Then, 

() h Witness[R, d*, f», c», d D , f 0 , c D , dA, fA, ca] : Witness R 
Definition C.4 (Identity Witness Function). Let I be a term and 
R : U —» * be a type. Then f is an identity witness function if one 
of the following is true: 

• () b f : Dist* R and for all n, T2, and e, we have that 
f n T 2 e =p e. 

• () b f : Factor, R and for all n, 75, and e, we have that 
f Ti r 2 e =p e. 

• (} F f : Coerce, R and for all n, T2, r 3 , r 4 , ci, C2, and e such 
that Ci ei =p ei and C2 e2 =p ei for all ei, e2, we have that 
f ti T 2 t 3 r 4 Ci C2 e e. 

• () I- f : Dist n R and for all k, t, and e we have that f k t e =p 


Lemma C.7. IfT h e : r ► q, then R : U 




• {) h f : Factor□ R and for all ft, t, and e we have that 

• () h f : Coerce□ R and for all k, ti, T 2, Ci and e such that 
Ci 73 ei ei for all T3 and ei, we have that f ft t\ 72 ci e » 

• () I- f : DistA R and for all r, and e we have that f t c=$ e. 

• () b f : FactorA R and for all r, and e we have that f r e =p e. 

• (} h f : CoerceA R and for all n, 72, ci and e such that 
Ci ft ei =p ei for all ft and ei, we have that f f*j T 2 Ci e =p e. 

Definition C.5 (Identity Witness). Let R, d*,f t ,c*, d D ,f D , c n , d A , 
/a,ca be as in Definition C.3. Then Witness[R,d,,f«,c*, d n ,fa, c D , 
< 7 a,/a,ca 7 is an identity witness ifd*,f*,c*, d n ,f a , c n , c/a,/a, and 
ca are all identity witness functions. 

Lemma C.8 (Semantics of Identity Witnesses). Let w be an iden¬ 
tity witness. Then: 

1) w (Dist* R) wi n 7*2 e imfi e 

2) w (Factor* R) W 2 T\ T 2 e =p e 

3) If ci ei =p eifor all ei, 

and C 2 e 2 =,9 e 2 for all e 2 , then 
w (Coerce* R) W 3 ti T 2 cti 02 e e 

4) w (Dist n R) W 4 k t e =p e 

5) w (Factor^ R) W 5 sre =p e 

6) If c ei =p ei for all ei, then 

w (Coerce □ R) W6 ft t a c e e 

7) w (DistA R) w 7 k r e =p e 

8) w (FactorA R) w 8 r e =p e 

9) If c ei =p ei for all ei, then 

w (CoerceA R) W 9 r o c e e 

Proof. Straightforward, by definitions A.4, C.4 and C.5, and a few 
steps of /5-reduction. □ 

Definition C.6. For any identity witness w, and any terms f 1,..., f6 
(where w, fi,..., fe may be inferred by context), </>(e) denotes the 

Definition C.7. Let ibe a term. If <f>( f a) =9 <j>( a) for any term a, 
we say that f is a cp-identity function, or that f is cj>-id. 

Lemma C.9. 1. For all R, n, T2.' dist* R n T2 is <f>-id. 

2. For all R, n, 72: factor* Rri 72 is (p-id. 

3. For all R, n, 72, <71, 02, Ci, C2.' // c 1 and C2 are (p-id, then 
coerce* R n 72 <71 C72 Ci C 2 is (j)-id. 

4. For all R, ft, t: dist D R k t is cp-id. 

5. For all R, ft, t: factor^ R ft r is p-id. 

6. For all R, ft, r, <7, c: If c is p-id, then coerce n R ft r <7 c is 
p-id. 

7. For all R, r: distA R r is p-id. 

8. For all R, r: factor R t is p-id. 

9. For all R, r, a, c: Ifc is p-id, then coerceA Rrac is p-id. 

Proof. Straightforward, by Lemmas A.7 and C.8. □ 

Lemma C. 10. 1. Forall R, ti, 72 , Ci, C2.' //ci and C2 are (p-id, 
then reify* R n T 2 Ci C 2 w </>-/c/. 

2. Forall R, n, T2, Ci, C2tlfc\ and C 2 are </>-;//, then reflect* Rn T 2 < 
is (p-id. 

3. For all R, ft, r, c: If c a is cp-id for any a, then reify n R ft r c 
is (p-id. 

4. For all R, ft, r, c: Ifc a is cp-id for any a, then reflect^ R ft r c 
is (p-id. 

5. For all R, r, c: If c X is (p-id for any x. then reify A R r c is 
cp-id. 


6. For all R, r, c: Ifc x is <p-id for any x> then reflectA R r c is 
cp-id. 

Proof. Straightforward by Lemma A.8 and Lemma C.9. □ 

Lemma C.ll (Coercions based on identity witnesses). If ti 
12 = c, then c is cp-id. 

Proof. Straightforward by induction on the height of n 72 = c, 
and by Lemma C.9 and Lemma C.10. □ 

Lemma C.12. Suppose F, w, abs*, app*, abs n , app n> absA, and 
app A are as in Definition A.2, and that w is an identity witness. 
Suppose f = fold[F, w, abs*, app*, abs a , app a , abs a, app a ]■ 
Then for any context T, term e, and types r and n such that 
The: Fla : ft. t and T h n : ft, we have that: 


f r[a := nj SFf' app n ft (Aa : ft. r) : ft. T i) Ti 

Proof. Be the definition of fold[... ] and e, we have that: 
fr[a := n] erf 

=/3 (c (mkApp n R ft (Aa : ft. r) e n)) 
w abs* app* abs D app n absA app A 

where r[a := n] r[a := n] = c. By Lemma C.ll, we have 
that: 

(c (mkApp n R ft (Aa : ft. r) e ti)) 
w abs* app* abs n app n absA app A 
=g (mkApp n R ft (Aa : ft. r) e n) 

w abs* app* abs n app n absA app A 
The result follows from a few steps of straightforward /5-reduction. 

□ 

Theorem 5.1. If T F e : r and {) F F : U —> *, then 
'll e : PExp F r. 

Proof. We have thatfe* g[R := F] and r F e : r ► q. By Lemma 
C.7, we have that R : U r F q : PExp R r. By weakening, 
'f-L F : U —f *. Therefore, F I e : PExp F r as required. □ 

C.l unquote 

Our self-recognizer unquote is defined in lib/unquotelib.pts. 
unquote= Aa : U. Ae : Exp a. fold[UId, witnessUId, id*, id*, id a , 
id D , id a, id a] a (e UId). 

Lemma C.13 (Types of unquote case functions). 

() t id* : (Ila : U. : U. (UId a —f UId fi) —f UId (Prod* a /?)) 

() h id* : (Ila : U. : U. UId (Prod, a fi) —f UId a -f UId 0) 

() h id D : (n X : na : x ^ U. 

(II/3 : x- UId (a 13)) -> UId (Prod D x a)) 
jfi F id D : (n X : □• Ila : x -» U. 

UId (Prod a x a) -»• (U/5 : X- UId (a 0))) 

() h id A : (Ila : □ —> U. (H X : □. UId a X )-> UId (Prod A a)) 

() h id A : (Ila : □ -f U. UId (Prod A a) -)• (n X : □. UId a X )) 

Proof. Machine checked. □ 

yheorem 6.1 (Type of unquote). 

p|| unquote : (Ila : U. Exp a —t UId a) 

Proof. Follows directly from Theorem A.8. □ 

Lemma C.14. witnessUId is an identity witness. 


Proof. Straightforward. Each witness function is an identity wit¬ 
ness function. □ 





Lemma C.15. Let f = fold[UId, witnessUId, id*, id*, id D , id D , 

Ma, Ma]. tft b e : r ► q, thenfrq =p e. 

Proof. Straightforward by induction on the height of T b e : r ► q, 
and by Lemmas C.14 and C.12 and Theorem A.ll. Note that each 
fold function is an identity function. □ 

Theorem 6.2 (Correctness of unquote). 

If {) \- e : t and quote(e) = q, then unquote t q =a e. 

Proof. Let f = fold[UId, witnessUId, id*, id*, id D , id n , idA, Ma]. 
Then unquote r q =b f r e. Result follows from Lemma C.15. □ 

C.2 isAbs 

isAbs is defined in lib/isAbslib.pts. isAbs = Aa : U. Ae : 

Exp a. foldfUBool, witnessUBool, isAbsAbs*, isAbsApp*, isAbsAbs a , 
isAbsApp n , isAbsAbsA, isAbsAppA] a (e UBool). 

Theorem 6.3 (Type of isAbs). 

II h isAbs : (Ila : U. Exp a -A Bool) 

Proof. From Theorem A.8, we have that isAbs : Ila : U.Exp a —> 
UBool a. The result follows from the conversion rule based on 
UBool a = Bool. □ 


C.3 cps 

cps is defined in lib/cpslib.pts. cps = Aa : U. Ae : Exp a. 
foldfCPS, witnessCPS, cpsAbs*, cpsApp*, cpsAbs n , cpsApp a , 
cpsAbsA, cpsAppA] a (e CPS). 


Lemma C.18 (Types of CPS functions). 


() b cps 

() h witnessCPS 
0 b cpsAbs* 

() b cpsApp, 

() b cpsAbs n 

{) b cpsApp a 

() b cpsAbs A 
1 I- cpsApp A 


U-S-* 
Witness CPS 


: (na 

u. n,s 

U. (CPS a -A CPS 3) -> CPS 

(Prod* a P)) 

: (na 

u. n,s 

U. CPS (Prod* a p) -a CPS a 

-A CPS P) 

: (n x 

□. na 

:X^U. 


(ns 

: x- CPS 

(a 3)) -A CPS (Prodo X a )) 


:(n X : 

: □. na 

:X^U. 



CPS (Prodo X a) -A Up : X- CPS (a /?)) 

: (na : □ -> U. (n X : CPS a X )-> CPS (Prod A a)) 
: (na : □ U. CPS (Prod A a) -A n X : □. CPS (a x)) 


Proof. Machined checked. □ 

Theorem 6.5 (Type of cps). 

(} b cps : (na : U. Exp a -A CPS a) 

Proof. Follows from Lemma C.18 and Theorem A.8. □ 


Lemma C.16. witnessUBool is an identity witness. 

Proof. Straightforward. Each witness function is an identity wit¬ 
ness function. □ 


Lemma C.17. Letf= fold[UBool, witnessUBool, abs*, app,, abs D , 
app n , absA, app A ], and suppose Their. 

• Ife = Xx : A.ei, then f r e s., true. 

• Ife = ei A, then fre=p false. 

Proof. Suppose e = Ax : A.ei. There are three cases: either 
() b A : *, or (} b A : or A = □. 

Suppose () b A : *. Then by Theorem A.ll, f r e 
(ATi : *. AT 2 : *. Af : Bool -A Bool.true) cri <r 2 (Ax : 
UBool A. f 02 eT) =p true, as required. 

The cases of |) b A : □ and A = □ are similar to the case of 
0 b A : *. 

Suppose now e = ei A. Again there are three cases: either 
() b A : Ti : *, or () b A : k : □, or () b A : □. 

Suppose () b A : n : *. Then T b ei : n A r 2 , and by 
Theorem A.ll, f r e =p app, n r 2 (f ri -A r 2 ST) (f rf A) =p 
false, as required. 

Suppose () b A : k : □. Then () b ei : (na : k. n). 
By Lemma C.16 and Lemma C.12, f r e =p app n n (Aa : 
k. Bool) (f (na : k. n) el) A =p false. 

Suppose () b A : □. Then T b ei : (nx : □. n), and by The¬ 
orem A.ll, f r e =p app A (Ax : n) (?Hy : □. n 1 ®) A 


Theorem 6.4 (Correctness of isAbs). 

If () b e : r : * and quote(e) = q then: 

• Ife = Xx : A.ei, then isAbs r q =p true. 

• Ife = ei A, then isAbs f q =p false. 

Proof. Let f = fold[UBool, witnessUBool, abs*, app,, abs D , app n , 
absA,app A ]. Suppose () b e : r and quote(e) = q. Then 
isAbs t q =p f re. The result follows from Lemma C.17. □ 





